Vendor concentration: the hidden single point of failure in IT
Why depending on a single infrastructure or software supplier is an operational risk, not just a negotiation position.
After the CrowdStrike incident in July 2024, many executives found themselves asking the same question: "Do we have concentrations like that?" The honest answer, in most cases, is yes. They are just not visible yet, because they have not materialized.
Vendor concentration is not only a cybersecurity question. It is a structural question about where in your infrastructure the single points of failure sit - the ones controlled by a third party.
What vendor concentration looks like
The most obvious form: one product installed on every server, every workstation, in every region, updating centrally. Any problem with that product is a problem everywhere at once.
A less obvious form: several different products owned by the same vendor, or drawing from the same cloud delivery infrastructure. It looks like diversification from the outside, but the single entry point remains.
Another form: functional dependency - a single supplier serving a critical process with no alternative. Not necessarily software. It could be a sole integrator, a sole connectivity provider, a sole license holder for a key system.
In all these cases the problem is not the vendor itself. The problem is that if the vendor stops working, your operations stop with it.
Why this concentration develops
Consolidation with a single vendor often looks reasonable piece by piece: volume discounts, one contract, simplified support, products that integrate with each other. Each of these decisions was made at a department level with local logic.
The systemic picture only appears when someone looks at the full dependency map at once. That typically happens after an incident, not before.
A second reason: the cost of diversification is visible immediately - an extra license, an extra integration, extra maintenance. The benefit of diversification is insurance. It only shows up when something goes wrong, and the probability of that seems low.
What to examine in a dependency audit
When I help companies work through vendor risk, I look at several dimensions:
Coverage: how many machines, systems, or users depend on the product with no alternative?
Access depth: what privilege level does the product or supplier have? Kernel-level access is a different risk class from a SaaS application.
Update propagation speed: does the product update automatically and immediately? Or is there a buffer?
Recovery speed: if the product stops working, how long does it take to return to normal - not for one machine, but for the entire fleet?
Alternative: is there a temporary replacement in case of failure - even a limited one?
What to do with concentrations once found
Not every concentration needs immediate remediation. Some risks are accepted consciously because the alternative is more expensive or technically infeasible in the near term.
But risk acceptance must be explicit. That means: document that the dependency exists, assess its weight, define the failure scenario, agree on who makes decisions when that scenario develops.
A risk that is not documented is not managed. It simply waits.
Three questions to start with:
- Are there components in your infrastructure that update automatically across the full fleet without a staging period?
- If a key vendor stopped working tomorrow for 24 hours - which of your processes would stop with it?
- Who in the company owns the vendor dependency map - or does no such map exist?