Inline or Out-of-Path, Always-On or On-Demand

These two decisions are routinely discussed as one, usually because a supplier’s product happens to combine them in a particular way. They are independent, and separating them makes both easier to reason about.

Inline or out-of-path is a question about topology: does traffic pass through the device?

Always-on or on-demand is a question about timing: is mitigation applied continuously, or started when something is detected?

An inline device can sit in the path and do nothing until told to act. An out-of-path device can have traffic permanently diverted to it. All four combinations exist.

At a glance

Appliance	Combination	Time to mitigation	What it costs
Inline, always-on	Immediate; the device is already in the path	The device is in the failure domain of all traffic, always
Inline, on-demand	Fast; enforcement is a policy change, not a route change	Same failure domain, plus a detection delay by choice
Out-of-path, on-demand	Detection plus diversion, typically minutes	Traffic is unprotected until diversion completes
Out-of-path, always-on	Immediate, but only for what is permanently diverted	A permanent detour, with its latency and its own dependency

Two of these four are common, one is a deliberate posture, and one is a contradiction people still buy. Read the second column against your own tolerance before reading the third.

The topology axis

Inline means the device is in the traffic path and sees every packet in both directions if the routing is symmetric. It can act on any packet immediately, because it is already holding it.

The cost is a failure domain. Everything that passes through the device depends on the device, every day, including the overwhelming majority of days with no attack. Hardware bypass reduces this to a brief interruption on power loss, and software faults are less reliably covered by it. This is why bypass mechanism, trigger conditions and measured failover time are specification items rather than details.

Inline also sees packets, which is the requirement for anything that inspects content or tracks protocol behaviour closely.

Out-of-path means the device sits beside the traffic. Detection normally comes from exported flow records — IPFIX or an equivalent — and mitigation requires redirecting traffic to the device, or pushing a filter upstream, before anything can be cleaned.

The cost is what flow records cannot show. Volumes, source distributions and protocol mixes are visible in excellent detail. Packet content is not, and neither is the fine-grained protocol behaviour that application-layer detection depends on. The granularity of the export sets a floor on what can be detected at all.

The benefit is that on an ordinary day the device is not in anyone’s path, which removes it from the failure domain entirely.

The timing axis

Always-on means mitigation is applied continuously. There is no detection delay before enforcement, because enforcement never stopped. The cost is whatever the mitigation itself imposes on normal traffic: added latency, connection-handling changes, and a false-positive rate that is now permanent rather than occasional.

On-demand means normal traffic passes untouched and mitigation begins when something is detected. The cost is the window: detect, decide, act. For an out-of-path design that window includes route convergence, which is where minutes come from rather than seconds.

That window is exactly what pulse attacks exploit. Short repeated bursts, each ending before the loop closes, can deny service continuously while a diversion-based defence never quite engages. An estate exposed to that pattern should be honest about whether its architecture can respond at all.

The four combinations

Inline, always-on. Immediate action, permanent failure domain, permanent cost on normal traffic. The right answer where time-to-mitigation dominates and the bypass path is trusted.

Inline, on-demand. The device is in the path but passive until needed, so acting is a policy change rather than a route change. Fast, and it keeps the false-positive cost off ordinary days. The failure domain is unchanged, which is the part people forget: the risk of being inline is paid whether or not the device is enforcing.

Out-of-path, on-demand. The classic scrubbing arrangement, described in diversion, cleaning and return. No everyday failure domain, no everyday latency cost, and a detection-plus-diversion window during which traffic is unprotected. Suits estates whose exposure is large volumetric events and whose tolerance for a few minutes of degradation is real.

Out-of-path, always-on. Traffic is permanently diverted through a device that is nominally beside the path. This can be sensible when the detour is short and the operator wants a consistent enforcement point, and it is a contradiction when it is bought for the failure-domain benefits of out-of-path while paying the detour cost of always-on. Ask what the detour costs in latency and what happens when the diversion path itself fails.

Deciding

Four questions, in order:

1. What is the tolerable time to mitigation? If it is seconds, out-of-path on-demand is already excluded and the conversation is short.
2. What is the tolerable everyday risk? An inline device is a dependency on days when nothing is attacking. Establish the bypass behaviour before accepting it.
3. What must be detected? Application-layer attacks need packets, which means inline or diverted. Volumetric attacks are visible in flow records.
4. Does the exposure include pulses? If it does, a diversion window measured in minutes is not a defence against it.

Most substantial estates end up with both layers rather than one: an inline stage sized to the circuit for what arrives, and an upstream diversion arrangement for what would fill it. The division and its economics are worked through in cloud, on-premises or hybrid, and the sizing arithmetic for the inline half in capacity sizing.