A CISO choosing an application delivery and application security platform will usually feel more comfortable with a well-known brand. The reason is practical: if something goes wrong, it is easier to explain that the organization chose a market leader. And if the brand is unfamiliar, they are likely to be more cautious when their technical team suggests evaluating it.
I understand that after more than twenty years in this industry. Large vendors bring scale, international coverage, partner ecosystems, and business continuity. But a decision that is easy to justify is not necessarily the one that manages real risk best.
No brand can guarantee bug-free software. What matters is what happens when a problem goes beyond the product itself.
When the problem goes beyond the product
When a customer of a large vendor needs urgent help, a non-standard adaptation, or support with a complex issue, I do not usually see a slow response. The vendor or its partner often reacts quickly. What takes longer is the resolution. And if the root cause is a product bug, the fix does not arrive immediately either.
A large vendor tends to focus on its own product: if it works as expected, it will not always go further. In enterprise infrastructure, however, the problem is rarely confined to a single component. An application depends on networking, security, load balancing, firewalls, cloud environments, and legacy systems at the same time. Each component can work correctly, and the customer can still have the problem. The vendor confirms that its product is fine, that the issue is not their problem, and the customer is left to deal with it alone.
This is where I see the value of a provider specialized in application delivery and security. For that kind of provider, one customer's problem may become the problem of many future customers, so it has a real reason to analyze it in depth. The customer also receives information directly from the team that develops the technology, without intermediaries: the vendor itself explains where the problem is and how to solve it. The difference is not who answers a ticket first, but how far the provider can go when the problem stops being standard.
Risk can change even when the product still works
I have seen this in a European organization that had been using an application delivery solution from a large non-European vendor for years. The product was stable, and the customer was satisfied. However, technological sovereignty, which is already part of the European debate, started to carry more weight in its strategy. The organization began to assess how dependent it was on a critical part of its infrastructure, how much control it wanted to retain, and what alternatives it would have if its priorities changed.
The technology kept working as before. What had changed was the way risk was being evaluated.
This does not mean that a European provider is better simply because it is European. It means that control, autonomy, dependency, and the origin of certain technologies can be legitimate criteria alongside performance, security, and availability.
And sovereignty is only one example.
The risk of a large vendor disappearing is usually low. What does materialize is the risk that its terms may change. This happened in virtualization: after Broadcom acquired VMware, enterprise user associations in Belgium, France, Germany, and the Netherlands complained about price increases and licensing changes. In April 2024, the European Commission requested information from Broadcom, which responded by announcing changes.
That is why, rather than asking whether the vendor will still exist in five years, organizations should ask how much room for maneuver they will have if the relationship no longer fits.
The cost does not end with the license
When I speak with customers using leading application delivery vendors, I always ask the same two questions: what do they value about the product, and what would they improve?
Most of them agree that the product works well, is stable, and does not fail. To a lesser extent, some say it is complex to use or that they are working with limited visibility, especially around the WAF. What they do question more often is the cost, and the cost of adding new capabilities.
When they consider switching, they worry about migration: retraining the team and having support throughout the process.
A more expensive solution is not automatically a bad investment. It may be justified if it delivers value, reduces risk, or simplifies operations. But licenses, support, training, maintenance, team time and a possible migration all belong to the same equation. The useful question is whether the total cost remains proportional to the value received, and how easily the organization could switch if it stops being so.
There is no universal answer
None of this means that one model is better than the other. If an organization needs forty different services, it has to ask whether forty vendors are manageable. Consolidation, integration, and the scale of a large vendor make complete sense. When depth in a specific area matters more, specialization offers something that scale does not always provide. In both cases, ask for continuity guarantees.
Before choosing, a CISO should be able to answer four questions: whether the technology fits their infrastructure, how the provider will respond to a non-standard problem, how the cost will evolve, and how much control the organization will retain if circumstances change.
A vendor's reputation can be part of that assessment, but it should not replace it. I believe a decision starts to become safe and defensible when it is tested: request a session, see the product, measure the response, and verify whether it solves the real problem.
For me, the question is not whether the organization chooses the best-known application delivery and security provider, but whether that decision will still be a good one a few years from now, when its needs, costs, or priorities have changed.
Comments