--- title: "CP-04 Physical Network Segmentation | Control by Firevault" url: https://fire-vault.com/control-plan/enforce-physical-segmentation description: "CP-04 separates selected trust zones with physically controlled crossings, so the connections between them exist only when the agreed design permits them." lang: en-GB --- Control Plan **CP-04**Physical Network Segmentation # Different trust levels need more than a shared network rule. Image: CP-04 Physical Network Segmentation Control Plan icon (https://fire-vault.com/__l5e/assets-v1/169a3eeb-e6af-451d-a864-f124db1e97e0/CP-04_physical-network-segmentation.png) CP-04 separates selected trust zones with physically controlled crossings, so the connections between them exist only when the agreed design permits them. Book a briefing: https://fire-vault.com/demo See Control in Action Plan CP-04 Purpose Physical Network Segmentation Selected connections 4 Modules Isolate · Fracture · Relay · Unlink Scope Selected physical crossings between agreed trust zones, including redundant members of the same boundary. What is at stake ## Why physical network segmentation matters. Flat or broadly connected networks let a problem in one area reach systems that should have been separate. Firewall rules matter, but some boundaries also need a physical control point. **Unnecessary standing crossings**Connections between zones can remain available because they were once needed. **Bypass routes**Redundant links and persistent support connections can bypass the intended boundary. **Unclear zone ownership**Without owners for each zone and crossing, exceptions accumulate over time. **Unknown dependencies**Disconnecting a crossing can affect services if the dependencies have not been mapped. The problem today ## Where you are IP connected today. CP-04 reviews four IP-connected paths in your business. While a path stays connected over IP, it is a route that can be reached, misused or exploited. Each path below carries its own risk to agree with its owner. **4**IP-connected paths reviewed **4**Risks to agree with owners **4**Control modules applied 1. _Risk 1_**Enterprise to operational zone** The selected crossing between corporate systems and an operational or supervisory zone. Whenever this path is open over IP, it is a route that can be reached, misused or exploited. **Agreed state:** Connected only where required for service 2. _Risk 2_**Engineering access crossing** The route used for approved engineering or administrative work. Whenever this path is open over IP, it is a route that can be reached, misused or exploited. **Agreed state:** Disconnected outside approved windows 3. _Risk 3_**Approved data exchange crossing** A selected crossing used for scheduled transfers between zones. Whenever this path is open over IP, it is a route that can be reached, misused or exploited. **Agreed state:** Disconnected outside transfer windows 4. _Risk 4_**Persistent support dependency** A standing relationship identified as bypassing the agreed boundary. Whenever this path is open over IP, it is a route that can be reached, misused or exploited. **Agreed state:** Removed or controlled after review Matching industry Blueprints BP-01 · utilities water (https://fire-vault.com/control-blueprint/utilities-water)BP-03 · oil and gas (https://fire-vault.com/control-blueprint/oil-and-gas)BP-05 · aviation (https://fire-vault.com/control-blueprint/aviation)BP-06 · telecommunications (https://fire-vault.com/control-blueprint/telecommunications)BP-07 · banking (https://fire-vault.com/control-blueprint/banking)BP-08 · healthcare (https://fire-vault.com/control-blueprint/healthcare)BP-09 · defence (https://fire-vault.com/control-blueprint/defence)BP-10 · colocations (https://fire-vault.com/control-blueprint/colocations)BP-11 · maritime (https://fire-vault.com/control-blueprint/maritime)BP-12 · motorsport (https://fire-vault.com/control-blueprint/motorsport)BP-13 · construction (https://fire-vault.com/control-blueprint/construction)BP-15 · education (https://fire-vault.com/control-blueprint/education)BP-16 · public sector (https://fire-vault.com/control-blueprint/public-sector)BP-17 · retail (https://fire-vault.com/control-blueprint/retail)BP-18 · utilities (https://fire-vault.com/control-blueprint/utilities) What Firevault changes ## What changes with this Plan. Define the crossings between trust zones, keep unnecessary crossings withdrawn and remove persistent dependencies that bypass the intended boundary. | Connection | Agreed normal state | Control action | | --- | --- | --- | | Enterprise to operational zone | Connected only where required for service | Isolate defines the boundary. Fracture withdraws the selected crossing. | | Engineering access crossing | Disconnected outside approved windows | Relay opens the crossing. Fracture withdraws it when the window ends. | | Approved data exchange crossing | Disconnected outside transfer windows | Relay opens the crossing for the exchange. Fracture withdraws it afterwards. | | Persistent support dependency | Removed or controlled after review | Unlink removes the dependency. Fracture controls any remaining physical crossing. | CP-04 does not replace firewall policy, inspect traffic, remove malware or control routes outside the approved register. Control in Action ## Physical Network Segmentation: see the selected path change. Control in Action Stage Before agreed physical control Flat or broadly connected networks let a problem in one area reach systems that should have been separate. Firewall rules matter, but some boundaries also need a physical control point.**Connected routes require review. Discovery checks your real dependencies.** **0**reached by the attack **10**still running Physical crossings - Enterprise to operational zone _Always connected_ - Engineering access crossing _Always connected_ - Approved data exchange crossing _Always connected_ - Persistent support dependency _Always connected_ - Recovery access (OSS) _Not in place_ 1. _IS_**Isolate** · Review the purpose and ownership of each selected connection. Illustrative selected connections, not an approved deployment. Agree service dependencies and authorised actions before implementation. This illustration does not predict attack reach or service availability. Offline Secure Storage® remains separate. The modules involved ## The Control modules behind this Plan. Treats the agreed crossings around a zone as one defined boundary. Physically withdraws a selected crossing. Opens a selected crossing for an approved purpose and time. Removes persistent support relationships that leave a bypass route available. ### CP-04Physical Network Segmentation Z0 Requesting environment Z1 Protected systems Z2 Related operations Held in Offline Secure Storage® Selected recovery material, held separately Out-of-band command path This Control Plan #### Define the crossings between trust zones, keep unnecessary crossings withdrawn and remove persistent dependencies that bypass the intended boundary. Primary modules: Fracture, Isolate, Relay and Unlink. Read the operational detail Module in this plan Image: Fracture module icon (https://fire-vault.com/__l5e/assets-v1/f709a192-16d2-4206-86f3-842a3200db9d/firebreak-icon.png) #### Fracture Controls the path Physically disconnects network paths to prevent unauthorised access, contain threats and stop an attack from progressing. Explore the Fracture module (https://fire-vault.com/control/modules/fracture) Concept illustration. Select any module to see what it does. Placement is drawn from your own network in discovery. Control Plans that work alongside CP-04 **CP-03****Third-Party Access Control**Supplier and vendor paths that exist only for approved work, in a defined window. _Open CP-03_: https://fire-vault.com/control-plan/control-third-party-access **CP-05****Critical Asset Protection**Separate business access from essential systems, with planned isolation boundaries. _Open CP-05_: https://fire-vault.com/control-plan/protect-critical-infrastructure **CP-02****Live Incident Containment**Physically disconnect the affected path during a live incident while the rest of the operation keeps running. _Open CP-02_: https://fire-vault.com/control-plan/contain-active-breaches See all Control Plans: https://fire-vault.com/control#blueprints How Control works: https://fire-vault.com/control As featured in - Read about Firevault on TechRadar Pro: https://www.techradar.com/pro/uk-startup-put-physical-disconnect-switch-in-its-cloud-storage-offering-to-mitigate-ransomware-attacks-but-will-that-be-enough - Read about Firevault on Yahoo Finance: https://uk.finance.yahoo.com/news/firevault-launches-help-businesses-directors-074500961.html - Read about Firevault on Channel Insider: https://www.channelinsider.com/security/tools-and-platforms/firevault-security-offline-platform-offering/ - Read about Firevault on Security Buyer: https://securitybuyer.com/uk-cybersecurity-startup-launches-firevault/ - Read about Firevault on SecurityBrief: https://securitybrief.com.au/story/firevault-unveils-offline-digital-vault-to-combat-rising-cyber-risks The Control Plan specification ## Each selected connection, written down. Enterprise to operational zoneThe selected crossing between corporate systems and an operational or supervisory zone._Connected only where required for service_ Normal state Connected only where required for service Authorisation Change approval or incident owner decision Module action Isolate defines the boundary. Fracture withdraws the selected crossing. Business effect Cross-zone access pauses. Confirm local operation before approval. Failure behaviour Behaviour agreed with the operational owner and tested. Engineering access crossingThe route used for approved engineering or administrative work._Disconnected outside approved windows_ Normal state Disconnected outside approved windows Authorisation Approved work with named purpose and window Module action Relay opens the crossing. Fracture withdraws it when the window ends. Business effect Engineering access is available only for approved work. Failure behaviour Remains disconnected unless an approved recovery procedure is followed. Approved data exchange crossingA selected crossing used for scheduled transfers between zones._Disconnected outside transfer windows_ Normal state Disconnected outside transfer windows Authorisation Approved schedule or exchange request Module action Relay opens the crossing for the exchange. Fracture withdraws it afterwards. Business effect Exchanges run only in agreed windows. Failure behaviour Persistent support dependencyA standing relationship identified as bypassing the agreed boundary._Removed or controlled after review_ Normal state Removed or controlled after review Authorisation Owner confirms that the dependency is not operationally required Module action Unlink removes the dependency. Fracture controls any remaining physical crossing. Business effect Reduces routes that bypass the zone design. Failure behaviour Confirm with the operational owner before implementation. Operational runbook ## Who does what, and when. What happens under normal conditions, during approved work, when an incident is detected and when connections are restored. Stage What happens Who decides On record _1_Normal operation **Agreed states held** Define the crossings between trust zones, keep unnecessary crossings withdrawn and remove persistent dependencies that bypass the intended boundary. Each selected connection sits at its agreed normal state. Set in the Plan, signed off by your operational, security and continuity leads. Connection states, continuously. _2_Approved work **Booked, bounded access** Isolate defines the boundary. Fracture withdraws the selected crossing.Relay Unlink The named owner approves each opening in advance. Request, approval, opening and closure. _3_Incident detected **Act on the alert** Your security tools raise an alert. The agreed action starts out of band, without depending on the network under attack. Pre-authorised in the Plan. The incident owner is told at once. The alert and the action taken. _4_Controlled response **Change the agreed crossings** Define the crossings between trust zones, keep unnecessary crossings withdrawn and remove persistent dependencies that bypass the intended boundary.Isolate Fracture Automatic only for the crossings you agreed. Anything else needs the incident owner. Each action, timestamped. _5_Reconnection **Check before reopening** Reconnect crossings one at a time after the zone owner confirms the agreed checks. The operational owner authorises each reconnection. Each check and each reconnection. Engineering and integration ## Fit the control around your existing environment. **Map the complete boundary**Confirm cabling, redundant links and alternate routes. A selected physical cut does not remove paths outside its scope. **Agree an independent command route**Confirm the available command methods for the selected hardware. Command delivery can be affected by coverage, roaming and handshakes. **Test the effect, not just the command**Verify the observed link state, service dependencies and failure behaviour in an agreed test window. Testing and evidence ## Prove the selected connection before relying on it. Agree acceptance criteria with the service owner, then retain the observed results. **Normal service**Check the agreed service state and alternate paths. **Controlled change**Verify approved opening, closure and the operational impact. **Recovery and failure**Test reconnection checks, loss of power and loss of the command route. Resilience and recovery ## Offline Secure Storage® OSS protects stored business data, recovery copies and retained evidence through physical disconnection. It is a separate storage service, not a Control module or a network containment function. Control by Firevault governs selected physical connections. Existing detection tools and authorised operators decide when to act. OSS does not detect incidents, command Control or replace operational safety procedures. Explore Offline Secure Storage (https://fire-vault.com/offline-secure-storage) Frameworks and limitations ## Support your obligations. Keep the boundaries clear. **What this addresses**Define the crossings between trust zones, keep unnecessary crossings withdrawn and remove persistent dependencies that bypass the intended boundary. **What it does not replace**CP-04 does not replace firewall policy, inspect traffic, remove malware or control routes outside the approved register. **Evidence agreed for the deployment**Specify the requests, approvals, commands, observed states and test results to retain. Logging capability and retention depend on the selected design. Build your Control Plan ## Start with the connections you would cut first. Choose one boundary, list every physical crossing and identify which ones must remain connected for service. Questions worth asking ## Before you rely on CP-04. Practical questions for the people who own these connections. Not by assumption. Map dependencies and agree the acceptable service impact with the operational owner before selecting a path. Your next step ## Take the next step with physical network segmentation. Book a briefing (https://fire-vault.com/demo) Prefer to talk first? Speak to the team: https://fire-vault.com/contact Book a briefing: https://fire-vault.com/demo Speak to the team: https://fire-vault.com/contact ## Structured data ```json [ { "@context": "https://schema.org", "@type": "Organization", "@id": "https://fire-vault.com/#organization", "name": "Firevault", "legalName": "Firevault Limited", "url": "https://fire-vault.com", "logo": { "@type": "ImageObject", "url": "https://fire-vault.com/logo.png", "width": 200, "height": 60 }, "foundingDate": "2025-03", "description": "Firevault is a UK cyber resilience company. Data protection and storage through Offline Secure Storage. Network evolution and rapid protection through Control.", "address": { "@type": "PostalAddress", "addressCountry": "GB", "addressLocality": "United Kingdom" }, "contactPoint": [ { "@type": "ContactPoint", "contactType": "customer service", "email": "hello@fire-vault.com", "availableLanguage": "English", "areaServed": [ "GB", "EU", "US", "AE" ] }, { "@type": "ContactPoint", "contactType": "sales", "email": "sales@fire-vault.com", "availableLanguage": "English", "areaServed": [ "GB", "EU", "US", "AE" ] } ], "founder": [ { "@type": "Person", "name": "Mark Fermor", "jobTitle": "Founder, CTO and CMO" }, { "@type": "Person", "name": "David Bailey", "jobTitle": "Founder and CEO" } ], "areaServed": [ "United Kingdom", "Europe", "United States", "Middle East" ], "sameAs": [ "https://www.linkedin.com/company/firevault", "https://x.com/firevaultuk" ], "slogan": "Disconnect to Protect", "brand": [ { "@type": "Brand", "name": "Offline Secure Storage" }, { "@type": "Brand", "name": "Control by Firevault" }, { "@type": "Brand", "name": "Firebreak" } ], "knowsAbout": [ "Offline Secure Storage", "Physically disconnected data storage", "Physical Air Gap Data Protection", "Ransomware Protection", "Ransomware recovery", "3-2-1-1-0 backup rule", "AI kill switch", "Operational technology security", "Critical national infrastructure resilience", "Data Sovereignty", "GDPR Compliance", "NIS2 Compliance", "DORA Compliance", "NCSC Cyber Assessment Framework" ] }, { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://fire-vault.com/#website", "name": "Firevault", "alternateName": [ "Firevault", "Firevault UK", "Firevault Limited" ], "url": "https://fire-vault.com", "publisher": { "@id": "https://fire-vault.com/#organization" }, "inLanguage": "en-GB", "description": "Firevault is a UK cyber resilience company. Data protection and storage through Offline Secure Storage. Network evolution and rapid protection through Control.", "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://fire-vault.com/learn?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@context": "https://schema.org", "@type": "WebPage", "@id": "https://fire-vault.com/control-plan/enforce-physical-segmentation#webpage", "url": "https://fire-vault.com/control-plan/enforce-physical-segmentation", "name": "CP-04 Physical Network Segmentation", "description": "CP-04 separates selected trust zones with physically controlled crossings, so the connections between them exist only when the agreed design permits them.", "isPartOf": { "@id": "https://fire-vault.com/#website" }, "about": { "@id": "https://fire-vault.com/#organization" }, "primaryImageOfPage": { "@type": "ImageObject", "url": "https://fire-vault.com/images/og/og-base-platform.jpg" }, "inLanguage": "en-GB", "breadcrumb": { "@id": "https://fire-vault.com/control-plan/enforce-physical-segmentation#breadcrumb" } }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "@id": "https://fire-vault.com/control-plan/enforce-physical-segmentation#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://fire-vault.com" }, { "@type": "ListItem", "position": 2, "name": "Control Plan", "item": "https://fire-vault.com/control-plan" }, { "@type": "ListItem", "position": 3, "name": "CP-04 Physical Network Segmentation", "item": "https://fire-vault.com/control-plan/enforce-physical-segmentation" } ] }, { "@context": "https://schema.org", "@type": "WebPage", "name": "CP-04 Physical Network Segmentation", "description": "CP-04 separates selected trust zones with physically controlled crossings, so the connections between them exist only when the agreed design permits them.", "url": "https://fire-vault.com/control-plan/enforce-physical-segmentation" } ] ```