What Happens to Your DDoS Protection If the Vendor's Cloud Goes Offline?

Aviation and industrial control settled this vocabulary decades ago. A system that stops safely when something fails is fail-safe. A system that keeps performing its function in a degraded form is fail-operational. A brake is designed to be the first; a flight control surface has to be the second.

A DDoS defence is a flight control surface. It is needed precisely when conditions are abnormal, and a defence that ceases when something upstream of it is unreachable has chosen the wrong failure mode for the job it does.

The uncomfortable part is that most buyers never establish which they bought, because the question is not on any datasheet and does not come up in a demonstration.

At a glance

Appliance	Component	Typical failure mode when unreachable	What to require instead
Classification service	New traffic is not classified; policy freezes	Local classification, or a documented frozen-policy behaviour
Licence or entitlement check	Can fail closed and stop enforcement	A grace period measured in weeks, stated in the contract
Management plane	Policy cannot be changed during the incident	A local administrative path independent of the hosted console
Signature and reputation updates	Data ages; no immediate loss	Nothing; this is the acceptable dependency
Telemetry and reporting	Incident evidence is not retained anywhere you control	Local retention sufficient for your reporting deadline

Only the fourth row is a dependency worth accepting without argument. The other four decide whether a defence is still a defence on the day the supplier has a bad afternoon.

The dependency is usually not where you look for it

Where detection runs is the question most buyers ask, and it is the right question. It is also, for on-premises products, frequently not the one that bites.

A device can classify entirely on its own hardware, using its own observations, with no external analysis whatsoever — and still stop enforcing when it cannot validate a licence. The classification architecture is genuinely local. The product is not.

This arrangement is common, rarely documented as a dependency, and almost never surfaced in a tender, because the tender asked about detection and the answer about detection was true.

Four things that can be unreachable

The classification service. Covered separately, because it is the one everybody thinks about. If analysis happens elsewhere, losing the path freezes policy at its last state.

The licence or entitlement check. The one that matters most and is asked about least. Software that validates its right to run against a hosted service has to decide what to do when the service does not answer, and there are three possible answers: continue indefinitely, continue for a grace period, or stop. All three exist in this product category. Only the first two are compatible with a defence.

The management plane. Increasingly the console is hosted rather than on the device. This is convenient and generally sound, and it means that when the hosted console is unreachable you may be unable to change a policy — during the incident that made you want to change it. The question is whether a local administrative path exists at all, not whether the hosted one is reliable.

Update and telemetry paths. Signature and reputation feeds age gracefully and are the one dependency worth accepting without argument. Telemetry export is different: if incident records live only in a hosted system, an outage that coincides with an attack costs you the evidence for a reporting deadline as well as the protection.

Why the compound probability is not small

The supplier having an outage is the least likely route to this condition, and treating it as the scenario is why the risk gets dismissed.

The realistic routes are ordinary. International transit degrades under the attack itself — this is the case that should worry anyone, because the dependency fails at exactly the moment it is needed. A firewall change severs an outbound path that nobody documented as load-bearing. A certificate expires. An entitlement lapses because a renewal purchase order sat in an approvals queue for three weeks.

Each of these produces the same state as a supplier outage. Over a five-year term, the probability that none of them occurs is not the number people assume when they wave the risk away.

What to require, in writing

The specification language is short, and it is worth putting in the contract rather than the questionnaire:

On loss of connectivity to all supplier-operated services, the appliance shall continue to enforce its last known good policy for a period of not less than N days, shall remain administrable through a local interface, and shall retain incident telemetry locally for not less than M days. The supplier shall state, per function, what degrades during this period.

Three numbers and one obligation. N should cover a procurement delay. M should cover the reporting deadline that applies to you — under NIS2 or DORA that is a defined period, not a matter of preference.

The final clause is the load-bearing one. A supplier willing to enumerate what degrades has thought about it. A supplier who answers that nothing degrades has usually not tested it.

Testing it properly

The test is easy to run and easy to run badly.

Block the appliance’s outbound path to the supplier at the perimeter — not by unplugging its data path, which tests something else entirely — and then leave it blocked. The duration is the whole test. Grace periods are timers; a device disconnected for an hour behaves identically whether the grace period is two days or ninety, and a short test therefore proves nothing about the property you are trying to measure.

Run the attack scenarios at the start of the window and again at the end. Watch for the second run to differ from the first, which is the signature of an expiring entitlement rather than a lost feed.

Where a full window is not available, require the behaviour contractually instead. An untested contractual term is weaker than a measurement and much stronger than an assumption.

The honest position

None of this argues for avoiding suppliers with cloud components, which would be an argument against most of the category and against several genuinely good products. A hosted console is better than a neglected local one. A shared intelligence feed sees things your network cannot.

What it argues for is knowing which components are in the enforcement path, because a dependency you have chosen is a risk you can plan around and a dependency you discovered during an incident is an outage. The same reasoning applied to supplier jurisdiction rather than supplier availability is worked through in vendor jurisdiction risk, and the extreme case — environments where no external path is permitted at all — is air-gapped mitigation.