None of the security tools was wrong. All of them together were.

I once sat in front of a computer running two, at times three, system scans at the same time. Plus the VPN. The machine was busy watching itself, and I sat there and waited. Not once, but for weeks.

Every single tool had its justification. Every purchase had been properly argued, by somebody who knew what they were doing and who closed a real gap. Only nobody had ever checked what happens when all of them work at once.

That is not an anecdote about slow computers. It is the basic pattern by which security comes into being in most companies.

Why this happens technically at all

Security software does not run beside the operating system, it runs inside it. Real-time protection hooks deep into file access so that it sees every operation. When two solutions do the same thing in the same place, they compete for the same access. Vendor documentation from several manufacturers has described this consistently for years; the range runs from noticeable slowdowns to system crashes and, in the end, to neither solution detecting reliably.

The usual answer is exclusions. You exclude directories and processes from each other’s scanning so that the systems stop getting in each other’s way. It works, and it has a price that rarely gets discussed. Every exclusion is a deliberately opened gap. Once it is set, because a performance problem had to be solved, it often outlives the software it was meant for.

What emerges is a system that looks doubly protected from the outside and carries, on the inside, a map of exceptions that nobody knows completely any more.

The numbers behind it

Larger companies today run 75 security tools in parallel on average, 79 above ten thousand employees. That is not the aberration of a few organisations, it is the average across a survey of five hundred security executives.

What follows from it can be quantified. The Microsoft and Omdia report on the state of security operations in 2026 finds that forty-six per cent of all alerts are false positives. Nearly half of an analyst’s work therefore produces no security value. A survey by Vectra AI from the same year arrives at just under three thousand security alerts per day and organisation, of which sixty-three per cent go unaddressed.

You can read that as a staffing problem. I consider it an architecture problem. Anyone running seven systems that all see the same anomaly and all report it separately does not have sevenfold visibility. They have sevenfold noise.

The commercial side looks similar. Zylo’s SaaS Management Index for 2026 finds that thirty-six per cent of all licences go unused on average. Other surveys come out higher: for the first quarter of 2026, Vertice counts fifteen per cent of applications that are never used at all, and a further fifty-one per cent running at less than half the purchased capacity.

And the consequence has long been drawn. Gartner has surveyed how many organisations actively want to reduce their security vendors. The figure rose from twenty-nine per cent in 2020 to seventy-five per cent in 2022. Consolidation is no longer a forecast, it is the intention of the majority.

The customer who buys what they already have

And then you sit with the customer and see the same pattern from the other side.

Somebody asks for a solution they have had in the building for years. It sits in a product that has been running for a long time, in a module that was licensed along with it and never activated, or in a feature that arrived two versions later and never appeared in any training. The colleague who was responsible for the purchase back then has left. The documentation ends at installation.

That is not carelessness on the part of individual companies. It is the predictable consequence of the fact that almost nowhere is there a reliable inventory of what actually runs in the building and what it can do. In theory a configuration database solves this, with every system recorded together with its attributes and relationships. In practice that database is precisely the part that goes stale first, because nobody is accountable for maintaining it and because it is not a project but a habit.

Without it, a strange inversion takes place. The company knows the market better than its own estate. For new products there are webinars, analyst reports and salespeople who call. For the installed base there is nobody whose job that is.

Since 6 December 2025 this is no longer merely a business problem. NIS2 applies in Germany with no transition period, around 29,500 companies now fall under the supervision of the BSI, and the law demands risk management that can be demonstrated. A sprawl that nobody fully oversees is by definition not demonstrable. Anyone falling under NIS2 or critical-infrastructure rules no longer has the inventory problem ahead of them as a tidying-up task, but as an obligation.

Why people buy anyway

At this point the comfortable reflex kicks in: there is too much choice on the market and it paralyses. It is not that simple, and the research is surprisingly ambiguous.

The first large meta-analysis of the effect concluded, across all the experiments examined, that too much choice does not overwhelm on average at all. Only the second meta-analysis, based on 99 observations from 53 studies with over seven thousand participants, showed what it actually depends on. Four factors decide. How difficult the decision task itself is, for instance because products are described by many attributes or because there is time pressure. How complex the choice set is, in particular whether there is a clearly dominant alternative. How uncertain the buyer is about their own preferences, which is above all the case with new product categories. And which goal they bring, a specific one or a browsing one.

Lay those four factors side by side and hold them against the security market, and the result is immediate. Products with dozens of attributes. Permanent time pressure from incidents and regulation. No dominant alternative, but twenty vendors all writing the same word on the slide. Constantly new categories in which nobody in the building has experience. And a goal that was often set from outside, for instance by an audit finding.

That is the constellation in which overload actually arises. And overload in procurement rarely leads to doing nothing. It leads to the most visible option, and the most visible option is almost always a new product.

The sprawl, then, is not an accident of operations. It is the expected outcome of a market that communicates differentiation badly, and of a customer side that does not know its own estate.

What this means for sales

I sell, I do not buy. But that is exactly why I see this situation several times a month. Four things I have learned from it.

1. The inventory question belongs in the meeting, not in the preparation. The question of which functions from existing contracts could be used today belongs in the first meeting. Not as a rhetorical trick, but because the answer changes the whole conversation. In half the cases something comes out of it that the customer did not have on their radar.

2. The most honest meeting is the one where you sell nothing. You do not need that, you already have it. That sentence costs you an order in the short term. It wins you a position from which the next enquiry no longer arrives through a tender but through a phone call. Anyone who takes that for idealism should look at how long a replacement sale lasts when the customer notices after eight months that they have paid twice.

3. You sell against the sprawl, not against the attacker. The threat situation no longer needs explaining to anyone in the mid-market. What is missing is not awareness, it is overview. A sales conversation that starts with a threat addresses a problem the customer already has. A conversation that starts with an inventory question addresses the problem they are actually stuck on.

4. The integration question is the real purchase decision, and it is asked too late. Not whether a product has a feature, but whether it talks to what is already there. Anyone asking it only during implementation has extended the sprawl by one more element.

How to set up a sales team for this

The four points above sound like the attitude of individual salespeople. They are not. No salesperson says “you already have that” voluntarily if their target agreement punishes them for it. Whether a team can sell that way is not decided in the customer meeting but before it, in three decisions by leadership.

1. The inventory question is mandatory, not optional. It belongs as a fixed part of every first meeting and every meeting preparation, as naturally as the question about budget. That can be demanded and followed up, in pipeline reviews as much as in ride-alongs. Give it to a team as a recommendation and you get it in one meeting out of ten. Set it as a standard and ask for it yourself and you get it in nine.

2. The target system has to withstand the forgone sale. A sales team measured exclusively on new licences will never sell against the sprawl, because it needs the sprawl itself. Put installed-base development, renewal rate and depth of usage at the customer into the targets, and behaviour changes without a single appeal to honesty. The short-term order left on the table by an honest meeting is a leadership decision. If leadership does not cover it, nobody carries it.

3. The team has to be able to read the customer’s estate. Most enablement programmes train the company’s own portfolio. What a salesperson needs for these conversations is the opposite. They have to recognise what sits inside an existing landscape, which modules of a competitor’s product typically lie idle and where functions overlap. That is presales knowledge that has to reach sales, and it does not come from product training but from joint inventory sessions at the customer.

That is the difference between a sales organisation you administer and one you build. Administering means taking over the target system and collecting the numbers. Building means deciding which behaviour you want to see at the customer, and then arranging everything behind it so that this behaviour is rewarded.

The real problem is not the number

The figure of seventy-five is easy to argue about, and it makes a good headline. It still misleads.

A company with seventy tools that know each other, hand events to a common place and share a common inventory is better off than one with fifteen isolated solutions. The problem is not the quantity. It is that none of them knows about the others.

In most companies IT management and security run side by side rather than together. One side knows which devices exist, which software sits on them and what state they are in. The other side decides which of that is a risk. When those two sides hold separate data, neither can do its job properly. Security assesses risks on an inventory it does not control. IT management maintains an inventory whose security relevance it does not judge.

Few vendors really solve this. Most would rather sell the next module, and that is not malice but the logic of a business model that earns on features sold and not on features saved. Which is why the pressure to consolidate will not come from the vendor side. It comes from customers who count their exclusions.

Elsewhere I have described why security projects in production fail because their success is invisible. With sprawl it is the other way round. Here the success is immediately visible, because people can use their computers again. Only nobody puts it on their banner, because a switched-off scanner appears in no target agreement.

Security that paralyses daily work is not security. It is just more expensive.