Firevault, offline secure storage, physically disconnected from the internet
Pricing

Control module · Fire layer

FV-Isolate. Separate, contain and limit reach.

Isolate divides systems and networks into controlled zones so a problem in one place cannot freely become a problem everywhere. Trust does not extend across a boundary unless the boundary is intentionally opened for a defined purpose.

As featured in

  • TechRadar Pro logo
  • Yahoo Finance logo
  • Channel Insider logo
  • Security Buyer logo
  • SecurityBrief logo

The problem

Flat networks reward whoever reaches them first.

Separation is a design decision. Without it, every incident has the run of the building.

  1. A compromise in one zone is contained to the surface that zone exposes, rather than the whole estate.

  2. Zone membership accounts for the identity making the request, not just the address it came from.

  3. Zones are designed against operational reality, not inherited from the way switches happened to be wired.

Problem 1

Lateral movement.

Once an attacker is inside a flat or weakly segmented environment, the next system, the next share and the next credential are all one step away.

Answered byReduced blast radius

Problem 3

Drift over time.

Logical segmentation drifts as services are added, integrations are wired in and exceptions accumulate, until the original boundary is no longer the real boundary.

Answered byExplicit zoning

The scenario

Scenario:
Containing a compromise to its zone.

Isolate is the difference between an incident in one room and an incident in the whole building. Step through it, or play it through.

Step 1 of 4

Compromise

A workstation in a corporate zone is compromised through a credential reuse attack.

Illustration.

Designed
Boundaries are explicit, not implied by network topology
Bounded
Lateral movement is constrained by the zone it starts in
No inherited trust
Cross-zone access is requested, not assumed
Continuously enforced
Separation holds during normal operations and during response

Placement

Where Isolate holds the zone boundary.

Isolate enforces the zone and conduit model. Each protected zone is reachable only through a named conduit, and only when the conduit is authorised to be open. Grounded in IEC 62443-3-3 SR 5.1, SR 5.2 and SR 5.3, NIST SP 800-82 zone guidance and the Purdue Enterprise Reference Architecture.

Relies on

  • An explicit zone and conduit inventory that is maintained, not assumed
  • Out-of-band approval to open a conduit
  • Continuous evidence that each boundary is intact

Pairs with

FV-Isolate works alongside Firebreak, Relay, Lock and Validate. Firebreak® hardware is manufactured by Firevault.

IEC 62443 SR 5.1

Enterprise zone boundary

Defines the perimeter of the enterprise zone. Cross-zone traffic must use a declared conduit.

IEC 62443 SR 5.2

Control system zone (Purdue L3 to L2)

Holds the boundary between supervisory and process control. Engineering reach is named, not implicit.

Physically disconnected Offline Secure Storage: server, three drives and a padlock

IEC 61511

Safety instrumented system zone

Keeps the SIS separated from basic process control. A compromise of BPCS does not reach the safety layer.

NIST CSF PR.IP-9

Recovery and forensic zone

Recovery infrastructure sits in its own zone, reachable only when a restore operation is authorised.

Capabilities

What you get with every deployment.

Six things FV-Isolate gives a security team, from the first decision to the audit afterwards.

FV-Isolate

Explicit zoning

Zones are designed against operational reality, not inherited from the way switches happened to be wired.

FV-Isolate

Default-deny crossings

Cross-zone traffic is not allowed unless a specific path, purpose and approval exist.

FV-Isolate

Reduced blast radius

A compromise in one zone is contained to the surface that zone exposes, rather than the whole estate.

FV-Isolate

Independent recovery

Each zone can be investigated, recovered and brought back online without waiting on the others.

FV-Isolate

Identity-aware boundaries

Zone membership accounts for the identity making the request, not just the address it came from.

FV-Isolate

Evidential record

Boundary changes and cross-zone approvals are recorded through Archive on physically separate storage.

Adoption guide

From first workflow to routine operation.

Four steps, piloted on one workflow before it extends across the estate.

  1. 1

    Map the estate

    Identify the systems, services, identities and data flows that should sit together and those that should not.

  2. 2

    Design the zones

    Define zones around operational reality, with explicit ownership and explicit cross-zone rules.

  3. 3

    Validate the boundary

    Test the boundary with realistic scenarios, including credential abuse and inherited trust paths.

  4. 4

    Operate and review

    Run Isolate as part of normal change control and review crossings through Archive on a regular cadence.

Playbooks

Which playbook covers this module.

Each playbook shows where this module sits in a real deployment, who authorises it and how a pilot scales into rollout.

Control for Water: Deployment Playbook

Defines the zone model that path control operates between, from telemetry through to enterprise systems.

Read the playbook

A Control Blueprint for Aerospace and Aviation

Shows how zones are drawn between engineering, production and airside environments without disrupting flight operations.

Read the playbook

A Control Blueprint for AI: 2026 Playbook

Separates model development, weights custody and production inference into controlled zones.

Read the playbook

All playbooks

Questions

Frequently asked about Isolate

It goes further. Logical segmentation drifts as services, integrations and exceptions accumulate. Isolate holds an explicit zone and conduit model, where each protected zone is reachable only through a named conduit, and only when that conduit is authorised to be open.

Zones are designed against operational reality, not inherited from the way switches happened to be wired. Adoption starts by mapping the systems, services, identities and data flows that should sit together and those that should not.

The crossing is requested, not assumed. Cross-zone traffic is allowed only when a specific path, purpose and approval exist, typically as a time-bound Relay session, and the approval is recorded through Archive.

Isolate runs as part of normal change control, with continuous evidence that each boundary is intact, and crossings reviewed through Archive on a regular cadence.

All questions

Decide what stays connected.

We will walk your architecture, show where FV-Isolate sits on each path, and the evidence it leaves behind.