How DDoS Vendors Lock You Into Their Ecosystem

Back to Blog

We build Flowtriq using open standards (standard BGP, REST APIs, webhooks). We have a clear interest in arguing for vendor-agnostic approaches. That said, the lock-in patterns described here are documented in vendor architecture guides and confirmed by operators who have experienced them.

The pattern of closed ecosystems

DDoS protection does not exist in isolation. It integrates with routers, firewalls, monitoring systems, ticketing platforms, scrubbing services, and customer portals. Every integration point is an opportunity for a vendor to create dependency: make the integration work best (or only) with their own products, and the customer's switching cost increases with every connection.

This is not unique to DDoS. It is the standard enterprise vendor playbook. But in DDoS protection, the consequences of switching are more severe because the tool is a security control. Migrating your monitoring platform might cause a gap in visibility. Migrating your DDoS protection causes a gap in security. The stakes make operators reluctant to switch even when they know they are overpaying or underserved.

Arbor: the Sightline/TMS ecosystem

Arbor (now NETSCOUT) has the deepest lock-in in the DDoS market, built over two decades of carrier deployments. The Sightline/TMS architecture creates multiple dependency points:

Sightline-to-TMS signaling. Arbor Sightline (detection) communicates with Arbor TMS (mitigation) using a proprietary signaling protocol. When Sightline detects an attack, it sends mitigation instructions to TMS through this proprietary channel. You cannot replace TMS with a third-party mitigation appliance without losing the automated detection-to-mitigation workflow. If you want automated mitigation, you buy both Sightline and TMS.

ATLAS Intelligence Feed. Arbor's threat intelligence comes from their ATLAS global threat monitoring network. This data feeds into Sightline's detection algorithms, improving accuracy with global attack trend data. The ATLAS feed is exclusive to Arbor products. If you switch detection tools, you lose access to this threat intelligence, which may increase your false negative rate during the transition.

Arbor Cloud integration. For cloud scrubbing, Arbor offers Arbor Cloud, which integrates natively with Sightline for automated traffic diversion. Using a third-party scrubbing service (Akamai, Cloudflare) with Sightline requires custom integration and loses some automation capabilities that are native to the Arbor-to-Arbor path.

Peakflow-era APIs. Some Arbor deployments still use APIs that date back to the Peakflow era. These APIs are not RESTful, not well-documented for third-party consumption, and structured around Arbor-specific data models. Building integrations against them is possible but painful, and those integrations break when Arbor changes the API in a firmware update.

The cumulative effect: an operator running Sightline + TMS + Arbor Cloud with ATLAS feeds has four proprietary dependency points. Replacing any one component requires rebuilding the integrations between the remaining components and the replacement. Replacing all of them requires a parallel deployment and a cut-over that carries real security risk.

Nokia (Deepfield): the router-centric model

Nokia's DDoS protection (via their Deepfield acquisition) is tightly integrated with Nokia router platforms. The architecture assumes Nokia routers as the primary telemetry source and mitigation enforcement point:

Nokia-to-Nokia telemetry. Deepfield's detection engine is optimized for telemetry from Nokia routers (7750 SR, 7950 XRS). While it can ingest standard sFlow/NetFlow from other vendors, the deepest analytics and fastest detection paths use Nokia-specific telemetry formats. Operators running Nokia routers get better detection. Operators running Juniper or Cisco get a degraded experience.

Automated mitigation through Nokia routers. Deepfield's mitigation capabilities are designed to push rules back to Nokia routers. Automated FlowSpec and RTBH work best through Nokia's routing infrastructure. Using Deepfield with non-Nokia routers for mitigation requires additional integration work and may not support all mitigation features.

The message is clear: if you run Nokia routers, Deepfield works well. If you do not run Nokia routers, it works less well. And if you deploy Deepfield and later want to switch to Juniper routers, your DDoS detection integration needs to be rebuilt.

Fortinet: the Security Fabric

Fortinet's DDoS product, FortiDDoS, is part of their broader Security Fabric ecosystem. The Security Fabric is Fortinet's architecture for integrating their full security stack: FortiGate (firewall), FortiAnalyzer (logging), FortiSIEM (SIEM), FortiManager (management), and FortiDDoS.

Within the Security Fabric, these products share telemetry, coordinate responses, and provide unified management. FortiDDoS can automatically signal FortiGate to block traffic. FortiAnalyzer aggregates logs from all Fortinet products. FortiManager provides a single pane of glass for policy management.

The lock-in is architectural: each Fortinet product works better when surrounded by other Fortinet products. FortiDDoS can function standalone, but it loses the automated cross-product coordination that is the Security Fabric's primary value proposition. An operator who deploys FortiDDoS alongside a Palo Alto firewall and a Splunk SIEM gets a functional DDoS tool, but misses the integration benefits that justified the purchase.

The progressive nature of Security Fabric lock-in is worth noting. An operator might start with a FortiGate firewall, then add FortiDDoS because it integrates natively. Then FortiAnalyzer because it works seamlessly with both. Each addition makes the ecosystem more valuable, but also makes every component harder to replace. By the time you have four Fortinet products, replacing any one of them breaks integrations with the other three.

Open-source tools with proprietary dashboards

Even tools that market themselves as open-source create lock-in through proprietary components. The detection engine might be open-source, but the web dashboard, the API layer, or the mitigation orchestration is commercial. Operators adopt the free tool, build workflows around it, and then discover that the features they actually need require a paid license that is not portable.

This is a common pattern in open-source infrastructure tools, not just DDoS. But it is worth noting because operators sometimes choose open-source tools specifically to avoid vendor lock-in, only to discover they have traded one form of lock-in (proprietary software) for another (proprietary features on top of open-source software).

"We chose an open-source detection tool because we wanted to avoid vendor lock-in. Three years later, we are paying for their commercial dashboard, their commercial API, and their commercial support. The open-source part is the detection engine that we could not use effectively without the commercial parts."

The switching cost inventory

When evaluating lock-in, it helps to inventory the specific costs of switching:

• Data migration: Historical attack data, baselines, and configuration are stored in vendor-specific formats. Migrating this data to a new tool ranges from difficult to impossible. Most operators accept that historical data stays with the old tool and start fresh.
• Integration rebuild: Every webhook, API integration, BGP peering session, and automation script that connects to the current tool needs to be rebuilt for the new tool. For a complex deployment, this can take weeks of engineering time.
• Staff retraining: Operators who have been trained on one tool's interface, terminology, and workflow need to learn the new tool. This has a direct productivity cost during the transition and an ongoing cost if the new tool is more complex.
• Parallel operation: Most operators run the old and new tools in parallel during the transition to ensure continuity. This means paying for both tools simultaneously, which can last 1-3 months.
• Security gap risk: During the transition, there is a period where neither tool is fully operational. The old tool may be partially decommissioned while the new tool is not yet fully configured. This gap represents real security risk.

For a large Arbor deployment, the total switching cost (engineering time, parallel licensing, retraining, risk mitigation) can exceed $200K. At that point, the incumbent vendor can charge almost anything for renewal because the switching cost is higher than any premium they might impose.

What vendor-agnostic looks like

A vendor-agnostic DDoS tool uses open standards for every integration point:

Standard BGP for mitigation. RTBH and FlowSpec are BGP standards (RFC 5635, RFC 8955). Any BGP-capable router from any vendor can accept these routes. The mitigation path does not depend on having a specific router vendor or a proprietary signaling protocol between detection and mitigation.

Webhook-based alerting. Instead of proprietary notification channels, webhooks send HTTP POST requests with structured JSON payloads. Any system that can receive HTTP requests can consume these alerts: Slack, Discord, PagerDuty, OpsGenie, custom scripts, or your own internal tools. The alert format is documented and stable.

REST API for data access. All attack data, configuration, and status information is accessible through a documented REST API. You can build your own dashboards, integrate with your existing monitoring stack, or automate workflows using standard HTTP tooling. The API does not require a vendor-specific SDK or client library.

Prometheus metrics for monitoring. Exposing metrics in Prometheus format means any monitoring system that supports Prometheus scraping (Grafana, Datadog, New Relic, or your own Prometheus instance) can ingest DDoS detection data. No proprietary agent, no vendor-specific collector, no custom integration.

No router vendor dependency. The detection system works the same regardless of whether your routers are Cisco, Juniper, Nokia, Arista, MikroTik, or Linux-based. Detection happens at the server level, not the router level, so there is no router vendor coupling.

How to evaluate lock-in before you buy

Before committing to a DDoS tool, ask these questions:

• Can I export my data? Attack history, baselines, and configuration. In what format? Is there an API for bulk export, or do I need to submit a support ticket?
• What happens to my integrations if I switch? Which integrations use vendor-specific protocols and which use open standards? How much engineering time would I need to rebuild them?
• Does the mitigation path require specific hardware? Can I use the tool's automated mitigation with any BGP-capable router, or does it only work with specific vendors?
• What are the contract terms? Multi-year contracts with early termination penalties are a form of lock-in. Month-to-month contracts reduce switching costs.
• Is the API documented publicly? If the API documentation is only available to licensed customers, you cannot evaluate the integration depth before buying.

No tool is completely lock-in free. Every tool creates some dependency through the time invested in learning it, configuring it, and integrating it into your workflow. But there is a meaningful difference between tools that create dependency through competence (you stay because it works well) and tools that create dependency through architecture (you stay because leaving is too expensive).

The former is earned. The latter is engineered. Know the difference before you sign.