Security stacks grew by accumulation rather than design. The result costs a fortune, produces more alerts than anyone can read, and leaves gaps between products that nobody owns. How to consolidate without losing coverage.
Nobody set out to buy forty five security products. It happened one reasonable decision at a time.
An incident revealed a gap, so a tool was bought to close it. An auditor asked a question, so a tool was bought to answer it. A vendor was acquired and its product drifted, so a replacement arrived while the original stayed running because something still depended on it. A new platform came bundled with capability that overlapped three things already in place, and nobody had authority to switch any of them off.
Gartner has put large enterprises at around 45 security tools on average. Research from IBM's Institute for Business Value with Palo Alto Networks landed considerably higher, near 83 products across roughly 30 vendors. The figures disagree because everyone counts differently. What the numbers agree on is that analysts actively use a fraction of what is deployed on any given day.
The cost argument is the one that gets a consolidation project funded, and it is the less interesting half.
Nobody owns the seams. Each product covers its own domain competently. Attacks travel between domains. An intrusion that starts in identity, moves through endpoint and ends in cloud storage crosses three products, each of which saw a fragment that looked unremarkable on its own. The correlation that would have revealed it was nobody's job.
Every console is an alert source. Forty five products means forty five opinions about what deserves attention, and the aggregate volume is something nobody chose. That queue is the subject of the alert queue nobody works, and tool count is one of its largest inputs.
Expertise thins out. Running a product well takes real depth. Spread a small team across dozens and every one of them runs at default configuration, which is where most of the value is lost. A well configured product beats three unconfigured ones and it is not close.
Renewals stop getting examined. Past a certain count, nobody can hold the whole estate in their head, so contracts renew because cancelling requires an investigation nobody has time for.
The dangerous thing about a security tool nobody opens is not the licence cost. It is that the coverage map still counts it.
Somebody totals the licence spend, decides on a cut, and picks products to remove by price. Six months later a real incident exposes a capability that quietly left with the tool nobody could justify.
The failure is that the decision was made against a price list rather than against a capability map. Two products that look redundant on a feature comparison frequently are not, because one of them is doing something specific that only one engineer knows about.
Write down what you need to be able to do. Not products. Capabilities. Detect execution on an endpoint. Identify an internet facing asset you did not know about. Reconstruct who accessed a given record last Tuesday. Block a known malicious domain. Produce evidence that a control operated. Fifty or sixty statements will cover most organisations.
Map every product to the capabilities it actually delivers here. Not what the datasheet claims. What it is configured to do in your environment today. This exercise alone tends to be worth the effort, because it surfaces both the genuine overlap and the capability everybody assumed was covered and is not.
Find the singletons first. Any capability delivered by exactly one product is a concentration risk before it is a saving. Know those before you touch anything.
Then look at the overlaps. Where three products deliver one capability, you have a real decision. Keep the one that is best configured and best understood by your team, not the one with the strongest feature list. A slightly weaker product your engineers know deeply outperforms a stronger one they have never tuned.
Cut in stages and prove it. Disable rather than cancel. Run for a quarter. Confirm the capability map has not moved, ideally by testing rather than by asking. Then cancel.
Gartner's own research has reported around three quarters of organisations pursuing vendor consolidation, up dramatically from a few years earlier. Most of them are doing it for cost. The ones that benefit are doing it for coherence.
Every major vendor now argues for their platform over your point products. Fewer seams, shared data, one console, one contract.
Some of that is real, and the seam argument in particular is the strongest case they make.
What they do not put on the slide is that you are exchanging many small dependencies for one very large one. Your negotiating position at renewal weakens considerably. A vendor decision you disagree with becomes your problem across your whole estate rather than in one product. And migrating away later is a multi year programme rather than a switch.
That is not an argument against consolidating. It is an argument for going in with your eyes open, keeping your data in a form you can take with you, and knowing what your exit looks like before you sign. This is the same dependency reasoning we set out in infrastructure fails in chains, applied to your own supplier base.
The only honest measure of a consolidation is whether you can still detect and respond to the same things afterwards.
Map your detection coverage to MITRE ATT&CK before you start, so you have a baseline that is about techniques rather than products. Re run it after each stage. Where the two differ, you have either found a saving or created a gap, and the map tells you which.
A purple team exercise at the end is the version of this that cannot be argued with, because somebody executes the techniques and you observe what you actually saw.
We think most organisations are better served by fewer products, properly configured, with the seams explicitly owned by somebody. That is an unfashionable position for anyone who sells software, including us.
So to be direct about our own interest. CyberNexus and ControlGraph are not another console for your stack. They sit where the seams are, holding the control, the evidence, the owner and the obligations as one structure, which is the layer that tends to be missing rather than duplicated. If you already have something doing that job properly, you do not need ours.
Our GRC practice runs capability mapping as a specific engagement, and our VAPT team runs the before and after validation, which is the part that turns a consolidation from an assumption into a demonstrated result.
List the security products you pay for. Next to each, write the name of the person who configured it and the date it was last tuned.
The rows where you cannot fill in either column are your consolidation candidates, and you did not need a consultant to find them.
Gartner has put large enterprises at roughly 45. Research from IBM and Palo Alto Networks has reported figures nearer 83 products across about 30 vendors. The counts differ by methodology, but analysts actively use only a fraction of what is deployed.
It multiplies alert volume, thins out the expertise available per product so most run at default configuration, and leaves the seams between products unowned, which is exactly where multi stage intrusions travel.
Map required capabilities first, then map each product to what it actually does in your environment. Identify capabilities delivered by only one product before cutting anything, disable rather than cancel, and validate coverage after each stage.
It genuinely reduces seams and simplifies operations. It also concentrates dependency, weakens your renewal position and makes any future migration a large programme. Decide deliberately and keep your data portable.
Baseline detection coverage against MITRE ATT&CK before starting and re run it after each stage. Confirm with a purple team exercise, where techniques are executed and you observe what was actually detected.
A growing share of extortion skips the ransomware entirely. Nothing is locked, nothing breaks, and the first sign is an email naming files you recognise. Backups do not help with this one.
Read the article
Continuous threat exposure management is the phrase of the year and most implementations of it are a scanner on a schedule. What separates the version that changes decisions from the version that produces a longer list.
Read the article
Some of the most effective intrusions of the last two years used no malware at all. Somebody rang the help desk, sounded convincing, and got a password reset. Cloned voices have made that conversation harder to win.
Read the articleIf this raises a question about your own compliance position or your security operations, the quickest route is a direct conversation.
