Defense in depth is the strategy of stacking multiple, independent security controls so that if any one of them fails or is bypassed, others still stand between an attacker and the process. In operational technology, where a single compromised path can reach equipment that moves fluids under pressure, relying on any one barrier is a bad bet. This guide explains defense in depth as an overarching philosophy - how the layers are meant to be independent, how they combine, and why it is the framing that ties together specific controls like segmentation, firewalls, and access management rather than any one of them.
Defense in Depth in OT in one line: Defense in depth is a layered security strategy in which several independent controls are placed in series so that no single failure exposes the protected system. In OT it means an attacker would have to defeat perimeter controls, network segmentation, host hardening, access controls, and monitoring in turn, rather than slipping past one barrier to reach the process. The core principle is redundancy of defenses: because any individual control can fail, the design assumes it will and ensures others remain to contain the breach.
Defense in depth borrows its logic from physical security, where a vault is protected by a fence, a locked building, a guard, a safe door, and an alarm - not because any one is expected to fail, but because no single one is trusted to be perfect. Applied to OT, the same reasoning stacks controls at the network perimeter, at the boundaries between zones, on individual hosts, around user access, and in continuous monitoring. An attacker who defeats one layer is not through; they land in front of the next.
The property that makes this work is independence between layers. Layers that all fail for the same reason provide little real depth - if a single stolen credential unlocks the firewall, the servers, and the workstations alike, then five controls collapse into one. Genuine defense in depth uses layers that fail differently: a network control that does not depend on a host being patched, a host control that does not depend on the network being trusted, an access control that does not depend on either. The goal is that no single failure, misconfiguration, or stolen secret cascades through all of them at once.
This is also why defense in depth is a mindset rather than a product. It assumes that every control will eventually fail or be bypassed - a firewall rule will be too permissive, a patch will be missing, a password will leak - and it designs so that such failures are contained rather than catastrophic. The question a defense-in-depth review keeps asking is not 'is this control strong' but 'if this control were gone, what would still stop the attacker,' and if the honest answer is nothing, the design has depth on paper but not in practice.
It is easy to confuse defense in depth with the specific controls that implement it, but the distinction is important. Network segmentation, a DMZ firewall design, host hardening, application allowlisting, and zero-trust access are each a single layer. Defense in depth is the overarching decision to have many such layers, chosen so they complement and back one another up. You can deploy any one of these controls and still have a shallow defense; you achieve depth only by combining several independent ones deliberately.
This framing changes how you evaluate a security program. Rather than asking whether the firewall is well configured in isolation, defense in depth asks how the whole set of controls behaves when one is defeated. A strong firewall protecting a flat internal network still leaves everything exposed the moment the firewall is bypassed, because there is no second layer - that is a strong control without depth. Conversely, several modest controls layered independently can be far more resilient than one excellent control standing alone, because defeating them all requires several distinct successful attacks.
Defense in depth is therefore the organizing principle that tells you which layers you still need. Standards-based segmentation models, perimeter designs, endpoint controls, and access frameworks are the building blocks; defense in depth is the argument for using more than one of them and for making sure they do not share a common point of failure. When people describe OT security as an onion of concentric layers, they are describing defense in depth - the specific rings are the individual controls, and the multi-ring structure is the strategy itself.
In oil and gas SCADA, the process being protected is physical and consequential, so the case for depth is especially strong: a breach that reaches control equipment can affect pressure, flow, and safety systems, not just data. A defense-in-depth posture assumes any single protection can fail and layers others behind it - segmenting the control network from the enterprise, controlling and monitoring the traffic that must cross between zones, hardening the HMIs and engineering workstations, tightly managing who can access what, and watching for anomalies throughout. No one of these is trusted to be the whole answer.
Cloud SCADA changes the shape of some layers without changing the principle. When field data flows outward to a cloud platform such as Merobix over device-initiated connections, the field site can avoid inbound exposure entirely, which is itself a strong layer - but it does not replace the others. Segmentation still separates control from business systems, access controls still govern who can view and command, and monitoring still watches for the unexpected. The cloud model adds and reshapes layers rather than collapsing them into one, keeping the depth intact.
The practical value of the defense-in-depth mindset for operators is that it turns security from a hunt for a single perfect barrier into a deliberate stacking of imperfect but independent ones. It accepts that a remote site's firewall might be misconfigured, a credential might leak, or a device might go unpatched, and it insists that when that happens, something else still stands between the attacker and the wellhead. That assumption - plan for each control to fail, and make sure it is never the last line - is the whole point.
It means protecting the industrial process with several independent security controls stacked in series, rather than relying on any single barrier. An attacker would have to defeat the perimeter, then segmentation, then host controls, then access controls, then monitoring in turn to reach the process. The strategy assumes each control can fail and designs so that when one does, others still stand between the attacker and the equipment.
Segmentation, a firewall, host hardening, and access control are each a single layer. Defense in depth is the overarching strategy of deliberately using several such layers, chosen so they fail independently and back one another up. You can deploy one strong control and still have a shallow defense, because if it is bypassed there is nothing behind it. Depth comes from combining multiple independent controls, not from perfecting any one of them.
Because layers that all fail for the same reason offer little real protection. If a single stolen credential unlocks the firewall, the servers, and the workstations alike, then several controls collapse into one point of failure. Genuine defense in depth uses controls that fail differently, so that no single misconfiguration, missing patch, or leaked secret can cascade through all of them at once and reach the process.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.