When Vendor Safety Becomes Concentration Risk

Some of the safest technology decisions I have seen began with a long vendor relationship.

The engineers knew the product. The support team knew the failure modes. The seller knew which promises could be kept. The customer knew whom to call. Years of shared experience had removed uncertainty from difficult work.

That is real value. It should not be dismissed as legacy thinking.

The risk begins when familiarity is treated as resilience.

A company can have an excellent relationship with a strong vendor and still be exposed to one roadmap, one licensing model, one distribution channel, one set of security patches, one certification pipeline, or one group of specialists. If any of those changes faster than the organization can respond, the trusted path becomes a concentration risk.

The answer is not to abandon the vendor that helped build the business. It is to know exactly where the dependency lives... and to build another workable path before urgency chooses one for you.

A long line card is not diversification

Technology companies often describe themselves as multivendor because they can sell products from many manufacturers.

That is commercial access. It is not the same as operational competence.

A credible alternative requires trained people, tested designs, implementation methods, support coverage, monitoring, licensing knowledge, migration experience, security baselines, escalation relationships, and enough capacity to serve customers when demand moves suddenly.

If the original vendor encounters a major disruption, a logo on a partner page does not become a migration factory overnight.

I would test multivendor readiness with practical questions:

• Can the alternative be designed, quoted, delivered, secured, and supported without borrowing the original vendor team for every decision?
• Are reference architectures and acceptance tests already proven?
• Can monitoring, identity, emergency calling, recording, compliance, contact-center integrations, and customer data survive the move?
• Are the necessary certifications held by enough people to absorb real demand?
• Does the distributor and support chain have enough capacity and credit to operate under stress?
• Can customers move in stages, or does the alternative require a disruptive replacement?

If the honest answer is “we could probably figure it out,” the business has an option... but it does not yet have resilience.

The dependency can be measured

One public enterprise-technology integrator reported a visible change in its vendor mix over three years. Avaya and Cisco represented 41 percent and 25 percent of technology-offerings revenue in 2015. By 2017, the mix was 21 percent and 39 percent. The same filing said Avaya's 2017 Chapter 11 restructuring caused some customers to delay purchasing decisions, reduced collaboration product revenue, and created the possibility that customers would choose another provider or a lower-margin alternative. (https://www.sec.gov/Archives/edgar/data/1697152/000119312518091278/d507706ds1.htm)

Those figures do not prove that one event caused the entire shift. Acquisitions, new capabilities, customer demand, and broader market change were also part of the period. They do prove something more useful: vendor events can move customer timing, revenue, margin, and competitive position through an integrator's business.

Avaya's own public record shows why the effect could not be reduced to a temporary news cycle. The company entered Chapter 11 in January 2017 with approximately $6 billion in funded debt. Its filing described declining demand for hardware-centered communications, competition from Cisco and Microsoft, and substantial cash requirements that limited money available for research, development, and other competitive investment. It also reported extended customer procurement cycles during the restructuring. (https://www.sec.gov/Archives/edgar/data/1418100/000119312518007960/d427311d1012ba.htm)

In 2023, Avaya completed another financial restructuring. The company said the process reduced debt by more than 75 percent, provided roughly $650 million in liquidity, and lowered net leverage to less than 1x. Those were constructive changes, and the company continued serving customers throughout the process. The point is not that restructuring makes a vendor unusable. The point is that customers and partners still have to evaluate the operational effect of the uncertainty surrounding it. (https://www.avaya.com/en/newsroom/2023/pr-us-230501/)

Vendor concentration is not simply a percentage in a revenue report. It is the speed and severity with which a vendor change can reach a customer outcome.

The customer feels concentration before the dashboard explains it

A vendor event rarely arrives at the customer as a clean line labeled “concentration risk.”

It arrives as a quote that takes longer because terms changed. A renewal that needs another approval. A product allocation. A roadmap conversation nobody is ready to have. A migration proposal without enough engineers behind it. A security update that requires a release the customer has not budgeted to deploy.

The customer may hear that the provider supports many vendors, then discover that only one path has the people, process, and tooling needed for the environment they actually run.

This is where trust becomes operational.

Customers do not need a promise that nothing will change. They need evidence that the organization can recognize a change early, explain the available choices honestly, protect what still works, and move without losing the controls and integrations that matter.

A strong vendor relationship can help deliver that answer. So can a strong alternative. Resilience comes from having both.

Security dependencies do not disappear when the contract changes

Commercial diversification can happen much faster than technical decommissioning.

A new platform may be selected while the old one still holds administrator accounts, certificates, call-detail records, recordings, contact-center data, remote-support tunnels, monitoring credentials, firmware dependencies, firewall rules, service accounts, and emergency-routing logic.

That means a vendor transition can increase exposure before it reduces it.

CISA's guidance for communications infrastructure recommends monitoring vendor end-of-life announcements, using supported software, tracking vulnerability and patch notices, testing updates, and maintaining change-management processes that can handle both routine and emergency patching. (https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure)

CISA's software supply-chain guidance goes further on removal. It warns that end-of-life products can leave residual functions, credentials, trust relationships, and dependencies behind. It recommends dependency analysis, revoking access and trust artifacts, monitoring exceptions, isolating what cannot yet be removed, and testing that decommissioning actually occurred. (https://www.cisa.gov/sites/default/files/2024-08/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_CUSTOMER_508.pdf)

This is why “we moved to another vendor” is not a security control.

The security result is proven only when the organization can show what remains, why it remains, who can reach it, which patches and support paths still exist, how exceptions are monitored, and what evidence will close the transition.

Due diligence should continue after the selection

Vendor reviews often become most detailed before a contract is signed. The scoring is completed, the risk is accepted, and the relationship moves into normal operations.

The environment does not stay still.

Ownership changes. Debt changes. Products are acquired or discontinued. Support moves between business units. Licensing models change. Key engineers leave. A critical dependency reaches end of life. A distributor tightens terms. A new vulnerability changes the practical risk of waiting.

NIST's July 2026 Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide treats supplier research as relevant to both new acquisitions and existing systems. It calls out provenance, resilience, foundational cyber practices, supply-chain tiers, and ownership or control as components of the assessment. (https://csrc.nist.gov/pubs/sp/1326/final)

That is the right direction. Due diligence should be a maintained view, not a procurement artifact stored after approval.

For each vendor-dependent service, I want to know:

• Which customer and business outcomes rely on it?
• Which products, versions, licenses, and support agreements are in use?
• When do support, certificate, subscription, hardware, and contract milestones occur?
• Which people and partners hold knowledge or access that cannot be replaced quickly?
• Which monitoring, security, identity, recording, data, and compliance systems depend on it?
• What is the tested alternative, and how long would it take to use at meaningful scale?
• Which parts should be preserved even if another platform is introduced?

The last question matters. Diversification should not become erasure.

Preserve the expertise... remove the single point of failure

A healthy response to concentration risk is not a forced migration from a vendor simply because the relationship is large.

It is a deliberate treatment decision for each dependency:

• Preserve it where the vendor and the specialist knowledge continue to create differentiated value.
• Diversify it where a second product, distributor, skill pool, or support path reduces material exposure.
• Connect it where customers need an orderly hybrid period instead of a sudden replacement.
• Isolate it where unsupported or high-risk components must remain temporarily.
• Migrate it where the current path no longer meets the business or security requirement.
• Retire it only after access, data, monitoring, contracts, and technical dependencies are proven closed.

This is already visible in the enterprise communications market. The same integrator whose older filing documented a major Avaya-to-Cisco revenue-mix change now publicly describes broad Cisco capabilities across collaboration, networking, security, cloud, services, and Splunk. It also extended a multiyear Avaya partnership in July 2026 focused on mission-critical communications, customer experience, hybrid deployment, and protection of existing investments. (https://www.onec1.com/partners/cisco) (https://onec1.mediaroom.com/2026-07-14-Avaya-and-C1-Extend-Multiyear-Strategic-Partnership)

That is a better model for resilience than declaring an old relationship wrong. Build credible alternatives without discarding the people, knowledge, customer trust, and working systems that still have value.

What leadership should see

I would not give leadership one vendor-concentration score. A single number can hide the difference between revenue exposure and operational exposure.

The useful view separates at least six things:

• Commercial concentration: revenue, bookings, margin, rebates, renewals, distributor terms, and pipeline tied to the vendor.
• Customer concentration: installed base, critical workloads, regulated environments, contract promises, and migration tolerance.
• Technical concentration: platforms, versions, integrations, data, certificates, dependencies, and end-of-life dates.
• People concentration: certified engineers, escalation knowledge, architects, support staff, and succession depth.
• Security concentration: privileged access, patch dependence, remote-support paths, telemetry, incident coordination, and unsupported components.
• Transition capacity: tested alternatives, migration tooling, reference designs, available specialists, customer communication, and time to recover.

Then show the intersections.

Ten trained engineers may look sufficient until the dashboard reveals that eight support the same installed base, two hold the only migration experience, and both are already assigned to critical customer work. Two vendors may look diversified until one platform depends on the other's identity service, monitoring stack, distributor, or specialist team.

Business Intelligence should make those relationships visible. It should also show where the organization does not know the answer.

The next disruption should not be the discovery process

Vendor loyalty and vendor resilience are not opposites.

The best relationships can remain valuable for decades because people invest in the expertise, trust, and customer outcomes around them. That value becomes safer when leadership can see the dependency clearly, maintain another credible path, and protect the customer through change.

The next vendor event may be financial, technical, contractual, geopolitical, or security-related. It may be a restructuring, an acquisition, a product retirement, a licensing change, a critical vulnerability, or simply a roadmap that no longer matches the customer's needs.

The event should start a response... not an inventory.

In Issue 4, Part 2, I show how I use AI and Business Intelligence to build a living vendor-dependency map from approved evidence, surface the combinations that create real concentration, and help experienced people test transition options without giving an agent authority to make them.

If one vendor changed direction tomorrow, which customer promise would you have the hardest time tracing back to the systems, people, and support paths behind it?