Security Architecture Guide: Physical Isolation, Segmentation and Cyber Resilience

Share

Who this guide is for

This guide is written for security architects and senior engineers designing trust boundaries, segmentation and recovery architecture. It assumes familiarity with Zero Trust, the Purdue Model and IEC 62443.

What the architect is actually responsible for

• Defining trust boundaries and stating what each boundary is assumed to withstand.
• Mapping data flows and the attack paths that follow them.
• Designing failure domains so that a compromise in one does not propagate to all.
• Separating control planes, management planes and data planes.
• Removing circular dependencies between production and recovery.

Logical and physical isolation

Almost every control in a modern estate is logical. VLANs, policy, firewalls, conditional access and micro-segmentation are all configuration, and configuration is reachable by whoever holds the management plane. That is the assumption most architectures never state.

• Layer 3 controls depend on routing policy and on the devices enforcing it.
• Layer 2 segmentation depends on switch configuration and on the administrative domain around it.
• Layer 1 isolation removes the electrical path. There is nothing to reconfigure, because there is no route to permit.

See physical versus logical air gap and Layer 1 in practice for the detail.

Zero Trust, honestly applied

Zero Trust removes implicit network trust, but it moves the dependency onto the identity and policy plane. A mature architecture states what happens when that plane is the thing that fails. In most designs the answer is that every logical control fails open or fails unavailable at the same moment. A small number of physical boundaries around the recovery domain restores a floor beneath the design.

OT, the Purdue Model and IEC 62443

• Purdue levels remain a useful reference for zoning even where the model is flattened by modern connectivity.
• IEC 62443 zones and conduits map cleanly onto physical boundary enforcement.
• Safety and availability outrank confidentiality, so controls must fail into a safe, known state.
• Remote maintenance is the dominant route between enterprise and process networks.

Our Purdue Model diagram shows the zoning we use in blueprint work.

Architecture patterns worth adopting

1. A recovery domain administered separately from production, with no shared tier-zero identity.
2. Broker-mediated third-party access, where the path only exists while a validated session is live.
3. Physically enforced zone boundaries at the points where a lateral move would be most damaging.
4. Evidence capture written to a store the production estate cannot alter.
5. A defined critical set held with no electrical path to the live network.

Mapping modules to boundaries

Control by Firevault provides nine Control Modules. The FIRE layer governs the path: Firebreak breaks it, Isolate separates environments at hardware level, Relay mediates a controlled connection, Execute fires the action on signal. The VAULT layer governs the data and the record: Validate checks conditions before a path opens, Archive preserves evidence, Unlink removes a standing connection, Lock holds access behind identity and condition, Transfer moves data across a boundary under control.

Architects rarely deploy all nine. Choose the modules that enforce the boundaries your threat model says are load-bearing.

The questions to ask of any design

1. Which controls in this design are configuration, and who can change that configuration?
2. What is the blast radius if the management plane for this zone is compromised?
3. Does anything in the recovery path depend on the domain it is recovering?
4. Which boundaries would still hold with no power to the policy plane?
5. How is a boundary crossing evidenced, and can that evidence be altered from inside?

The evidence to expect

• Current data flow and trust boundary diagrams, with assumptions written down.
• An attack path model referenced to MITRE ATT&CK.
• Zone and conduit documentation for OT environments.
• Test results showing a boundary holding under simulated administrative compromise.
• A dependency-free recovery design, reviewed independently.

What happens when preventative controls fail

Prevention buys time. It does not remove the need to answer a simple question: if an attacker holds your identity platform and your management console tonight, what still works tomorrow morning? Most organisations discover that their backup catalogue, their recovery credentials and their runbooks all depend on the systems that have just been taken. That is the dependency worth removing first.

No control removes the possibility of a serious incident. The realistic goal is a smaller blast radius, a recovery path that does not depend on the compromised estate, and evidence that both were tested.

Deciding what you actually need

Architects should treat Firevault as a way to move a small number of load-bearing controls out of configuration and into physics. Everything else stays where it is. Firevault is the company. It provides three distinct things, and the honest answer is often that you need one of them rather than all of them.

• Offline Secure Storage® holds a defined set of critical records and clean recovery data physically disconnected from the live estate. It is a protected set, not a replacement for your backup infrastructure.
• Control Modules are a suite of nine purpose-built tools and techniques that give you physical control over the paths into and across your estate. Introduce only the modules that map to the risk you are treating.
• Control Blueprints are proven combinations of those modules assembled for a named outcome, such as containing a live breach or governing third-party access.

If your existing controls already deliver a tested recovery path that survives the compromise of your identity and management planes, and you can evidence it, you may not need any of this. Test that assumption before you buy anything. If you are unsure which of the three applies, the Firevault Concierge walks through the question set without a sales conversation.

The Control Blueprints most relevant to this role

All seven blueprints are relevant to architecture work, and each blueprint page carries its own topology. Control by Firevault is a set of nine Control Modules, grouped into the FIRE layer (Firebreak, Isolate, Relay, Execute) and the VAULT layer (Validate, Archive, Unlink, Lock, Transfer). Seven Control Blueprints combine those modules for a specific outcome. You do not need all nine modules, and most organisations start with one blueprint.

• CP-01 Stop Kill-Chain Ransomware uses Firebreak, Isolate, Execute. Read the stop kill-chain ransomware guide.
• CP-02 Contain Active Breaches uses Firebreak, Isolate, Execute. Read the contain active breaches guide.
• CP-03 Control Third-Party Access uses Validate, Relay, Lock. Read the control third-party access guide.
• CP-04 Enforce Physical Segmentation uses Firebreak, Isolate, Unlink. Read the enforce physical segmentation guide.
• CP-05 Protect Critical Infrastructure uses Firebreak, Isolate, Relay, Execute. Read the protect critical infrastructure guide.
• CP-06 Prove Compliance Through Control uses Validate, Lock, Archive. Read the prove compliance through control guide.
• CP-07 Protect Aviation and Aerospace Networks uses Firebreak, Isolate, Validate, Relay. Read the protect aviation and aerospace networks guide.

The full set is on the Control overview and the Control Blueprints index.

Where to go next

Read the CISO guide for the risk framing, the CIO and CTO guide for the estate view, and physical layer security architecture for the underlying principles.

Sources and further reading

• MITRE ATT&CK
• IEC 62443 series
• NCSC Cyber Security Design Principles
• NIST Cybersecurity Framework 2.0
• ISO/IEC 27001

About this guide

Author Mark Fermor, Firevault. Reviewed by Firevault engineering review. Last reviewed 28 August 2026.

This guide draws on primary regulatory and technical sources together with Firevault's own field work on physical isolation and offline recovery. It is guidance, not legal advice. Where a legal or regulatory duty is in question, take advice on your own circumstances.

Other guides in this series are listed on the role guide hub.

How Firevault would handle this

A recovery copy an attacker cannot reach

Offline Secure Storage® keeps a clean copy of your data on hardware that is physically disconnected, so backup and recovery do not depend on systems an intruder can touch.