The security market in 2026: the part nobody audits

Why does consolidation keep not happening?

Around three quarters of organisations report pursuing it, in survey after survey, year after year, while the tool counts described above keep rising. Both things are true, and the gap between them is structural.

Buying is a decision one person can make. There is a budget line, a business case, a supplier who will help write it, and a visible outcome: a capability that did not exist now exists. The whole apparatus of procurement is built to make this transaction happen.

Removing is a project. Somebody must establish what depends on the thing being switched off, which requires knowing what it does, who consumes its output, which dashboards reference it and whether an auditor was shown it last year. Then somebody must accept the risk of being wrong, on a change whose best possible outcome is that nothing happens. Nobody is promoted for that.

So the asymmetry compounds. Each new platform arrives promising to replace four products, and it does replace their function, but the four remain installed because removing them was a separate piece of work that was never scheduled. The estate grows by addition and shrinks only when a contract lapses and nobody notices in time to renew it.

The organisations that genuinely reduce their count do one specific thing differently: they make removal a condition of the purchase. The business case for the new platform names the products it replaces and the date they are switched off, and the project is not closed until they are gone. It is not a clever technique. It is simply putting the hard half in the same document as the easy half.

Does buying more reduce risk?

Nobody can demonstrate it either way at the level of a whole portfolio, and the reason is worth stating precisely rather than treating as cynicism.

Individual controls have evidence. Phishing-resistant authentication removes a category of loss and this is demonstrable. Offsite backups change ransomware outcomes measurably. Reachability analysis shortens a queue without lowering a standard. Those claims can be tested against what happens, and several other pages on this site rest on exactly that kind of evidence.

What has no evidence behind it is the aggregate: that an organisation spending twice as much is meaningfully safer than one spending half. To establish that you would need an outcome measure comparable across organisations, and the field does not have one. Breach counts are dominated by what gets disclosed. Incident counts are dominated by what gets detected, which is a function of tooling — so buying more detection raises your incident count, which is the opposite of the direction the measure would need to run.

That absence is the deepest problem in this section, and it is not going to be solved by the parties currently producing the figures. It is why the useful question for a specific purchase is never whether it improves security in general, but what it does that you can observe: which class of event stops happening, which piece of work stops being manual, which question becomes answerable in minutes.

What happens to a product after it is bought

With over a hundred and fifty tracked transactions in a single quarter, this is not an edge case to plan around. It is the base case for any supplier you choose today.

The pattern is consistent enough to be worth writing down. In the first year the product continues unchanged and both parties say the roadmap is safe. Around the eighteen-month mark the founders and much of the original engineering team reach the end of their retention and leave. Pricing moves into a bundle, which is presented as value and functions as a rise for anybody who wanted only this part. Integration work consumes the roadmap for a year, during which nothing the customer asked for ships. Sometimes the product is retired and customers are migrated to an adjacent one that does most of what they had.

None of that is misconduct. It is what acquisition is for, and the acquirer is buying a customer base and a capability to fold into a platform rather than a commitment to keep operating an independent product line.

The consequence for a buyer is that the evaluation should include a question that rarely appears in one. Not is this company stable, which invites a reassuring answer, but what do we do if this is acquired next year — and the answer has to be in terms of your data, your detections and your contract rather than in terms of trust.

Buying so that leaving is possible

Given the transaction volume, the only durable protection is arranging in advance that departure is affordable. Four clauses do most of the work.

Your data leaves in a documented format. Not an export button that produces something proprietary — a specified schema, retrievable in bulk, tested once during the first year rather than discovered during the last.

Detections and policies are expressible outside the product. Two years of tuning is the real switching cost, far more than the licence. If that work lives only inside the vendor's console, the renewal is not a negotiation.

Exit at renewal carries no engineered penalty. Multi-year terms with steep early-termination clauses and bundled pricing that collapses if one component is dropped are all mechanisms for making the second conversation easier than the first. They are negotiable at signature and not afterwards.

None of these four is unusual to ask for, and the reason they are rarely in contracts is that nobody raises them while the relationship is new and everybody is enthusiastic. That is precisely when they are cheap: a supplier competing for the business will concede terms that the same supplier, three years in and holding your detection library, has no reason to discuss.

Acquisition is addressed explicitly. Ask what happens to your terms if the company changes hands, and get the answer in the contract. It is a reasonable question, it is asked routinely in other industries, and the reaction to it tells you something on its own.

Where to start on a Monday

Three exercises, all internal, none requiring a supplier conversation.

Count your own tools twice. Once as consoles somebody signs into weekly, once as everything installed or licensed. Write both numbers down with their definitions attached. That pair is more useful in a board paper than any published average, and it is the only version of the figure you can defend.

Take the last statistic you cited and try the four questions on it. Who was asked, what exactly, who paid, could anybody reproduce it. Doing this once changes how the next one reads.

Pick your most critical supplier and ask how you would leave. Not as a threat — as an exercise. How does the data come out, where do the detections live, what does the contract say about a change of ownership. Most organisations discover they could not leave, which is worth knowing before the question is urgent.

After those three the harder work is prioritisable: making removal a condition of every purchase, building the one outcome measure you can actually observe, and renegotiating the terms that were signed when nobody was thinking about exit. An organisation that has done the first three can say what it owns and what it would cost to change its mind, which is more than the figures in this section can say about anything.

A closing note on tone, because a page like this invites the wrong conclusion. None of the above argues that the products do not work, that the people producing the research are acting badly, or that spending is wasted. Several controls this site recommends elsewhere are sold by the companies described here, and they work. The argument is narrower and harder to dismiss: an industry whose entire proposition is rigour about evidence has not applied that rigour to its own numbers, and until it does, every figure quoted about it — including the ones on this page — should be read as a claim rather than as a count.