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.
Control removes the physical path. Blueprints show where each module sits.
- Boundaries are explicit, not implied by network topology
- DesignedBoundaries are explicit, not implied by network topology
- Lateral movement is constrained by the zone it starts in
- BoundedLateral movement is constrained by the zone it starts in
- Cross-zone access is requested, not assumed
- No inherited trustCross-zone access is requested, not assumed
- Separation holds during normal operations and during response
- Continuously enforcedSeparation holds during normal operations and during response
Flat networks reward whoever reaches them first.
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.
Trust by topology
Permissions that exist only because two systems sit on the same subnet are permissions nobody chose to grant.
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.
Control Module - FIRE
Separation is a design decision. Without it, every incident has the run of the building.
The Scenario
Scenario: containing a compromise to its zone
A workstation in a corporate zone is compromised through a credential reuse attack. Because the corporate zone is isolated from the operations zone and from the records zone, the attacker's reach is limited to what is intentionally exposed to corporate, which is little. Investigation, eradication and recovery proceed in the affected zone while the other zones continue to operate. Cross-zone access for the responders is requested explicitly rather than already being available by default.
"Isolate is the difference between an incident in one room and an incident in the whole building."
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.
FV-Isolate
Control layer
Enterprise zone boundary
Defines the perimeter of the enterprise zone. Cross-zone traffic must use a declared conduit.
Control system zone (Purdue L3 to L2)
Holds the boundary between supervisory and process control. Engineering reach is named, not implicit.
Safety instrumented system zone
Keeps the SIS separated from basic process control. A compromise of BPCS does not reach the safety layer.
Recovery and forensic zone
Recovery infrastructure sits in its own zone, reachable only when a restore operation is authorised.
Relies on · prerequisites
- 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 · companion modules
Firebreak
Relay
Lock
ValidateFeatured In
Capabilities
What you get with every deployment
Explicit zoning
Zones are designed against operational reality, not inherited from the way switches happened to be wired.
Default-deny crossings
Cross-zone traffic is not allowed unless a specific path, purpose and approval exist.
Reduced blast radius
A compromise in one zone is contained to the surface that zone exposes, rather than the whole estate.
Independent recovery
Each zone can be investigated, recovered and brought back online without waiting on the others.
Identity-aware boundaries
Zone membership accounts for the identity making the request, not just the address it came from.
Evidential record
Boundary changes and cross-zone approvals are recorded through Archive on physically separate storage.
Demo to Live
Adoption Guide
Map the estate
Identify the systems, services, identities and data flows that should sit together and those that should not.
Design the zones
Define zones around operational reality, with explicit ownership and explicit cross-zone rules.
Validate the boundary
Test the boundary with realistic scenarios, including credential abuse and inherited trust paths.
Operate and review
Run Isolate as part of normal change control and review crossings through Archive on a regular cadence.
Map the estate
Identify the systems, services, identities and data flows that should sit together and those that should not.
Design the zones
Define zones around operational reality, with explicit ownership and explicit cross-zone rules.
Validate the boundary
Test the boundary with realistic scenarios, including credential abuse and inherited trust paths.
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: Control for Water: Deployment PlaybookA Control Blueprint for Aerospace & Aviation
Shows how zones are drawn between engineering, production and airside environments without disrupting flight operations.
Read the playbook: A Control Blueprint for Aerospace & AviationA Control Blueprint for AI: 2026 Playbook
Separates model development, weights custody and production inference into controlled zones.
Read the playbook: A Control Blueprint for AI: 2026 PlaybookExplore More
Questions