Unpatchable systems
Systems that cannot defend themselves
Controllers and instruments running unpatchable software were designed for isolation, then connected for visibility and reporting.
Control need · Segmentation that holds
Segmentation is usually described as a set of zones and enforced as a set of rules. The two are not the same thing. If a credential, a misconfiguration or a forgotten route can carry traffic across a boundary, that boundary exists on the diagram rather than in the estate.
As featured in




What is exposed
Where operational systems sit behind logical separation only, the exposure is easy to describe and uncomfortable to look at.
Unpatchable systems
Controllers and instruments running unpatchable software were designed for isolation, then connected for visibility and reporting.
Inherited compromise
When identity, monitoring or jump servers span both sides of the boundary, a compromise on one side inherits the other.
Hidden crossings
Engineering laptops, temporary links and supplier connections create crossings that never appear in the architecture record.
Physical consequence
In operational environments, the outcome of a crossing is not data loss. It is production stoppage, safety risk and service failure.
Why the exposure exists
Operational networks were connected for good commercial reasons. The problem is that the protection they previously relied on was physical, and what replaced it was configuration.
The honest position
Firewalls, VLANs and rule sets are valuable, and they are still configuration. Configuration is changed by people, inherited from previous teams and occasionally wrong. A boundary that matters to safety and continuity deserves an enforcement mechanism that does not depend on a rule being correct on the day.
Control the path, protect the asset.
Which paths need controlling
Rather than debating zone models, start by naming the crossings that exist today and deciding how each one should behave. Switch between today and with Control.
Who uses itReporting, planning and business systems
How it behaves todayPermanent route governed by rulesWhat Control governsPhysically closed by default, opened only for defined exchange
Who uses itInternal engineers and equipment vendors
How it behaves todayStanding access through shared jump hostsWhat Control governsScheduled window, named person, closed automatically
Who uses itHistorians, dashboards and analytics
How it behaves todayContinuous two-way connectivityWhat Control governsOne directional, defined route for the data that must flow
Who uses itIT administration and monitoring
How it behaves todaySpans both environmentsWhat Control governsSeparated, so a compromise on one side does not inherit the other
Zone models, level mapping and conduit design belong in the Blueprint. This page is about agreeing which crossings exist and which of them should stop being permanent.
What physical Control changes
Control puts a physical enforcement point on the crossings you have named, so the boundary holds regardless of what happens in configuration.
Today
Zones exist in policy and are enforced by devices that can be reconfigured, misconfigured or traversed with valid credentials.
With Control
Crossings exist only when they have been opened for a purpose, and the closed state is a property of the hardware rather than of a rule.
In operational environments, the consequence of a crossing is measured in downtime and safety, not in records.Connected when approved. Disconnected by default.
The Control philosophy
Control restores the discipline that operational environments used to get from physical separation, without giving up the visibility that convergence delivered.
Every incident that spreads does so along a connection that was already there. Control begins by naming that connection in plain language, before anyone talks about products.
A path that exists only when it is needed cannot be used at three in the morning by someone who should not have it. Disconnection is the resting state, not the emergency response.
When work genuinely needs a connection, Control opens it for a named person, a stated purpose and a fixed period, then closes it again without anyone having to remember.
A policy says the path should be closed. Physical control shows that it is. That difference is what auditors, insurers and boards are actually asking about.
Where this goes next
With the crossings agreed, the Blueprint sets out the zone architecture, the enforcement points and the phased deployment that gets there without interrupting production.
CP-04 Enforce Physical Segmentation
Segmentation should not just be logical. It should be physically enforceable. Applied to trust boundary enforcement between zones.
Lead module
Physically opens or closes connection paths to prevent unauthorised access and stop attack progression.
Read FV-FirebreakLead module
Separates systems and networks into controlled zones to reduce lateral movement and enforce trust boundaries.
Read FV-IsolateLead module
Removes persistent connections, live dependencies and inherited trust that keep sensitive assets exposed.
Read FV-UnlinkQuestions
Deployment is phased and designed around operational constraints. Control sits at boundaries rather than inside control systems, so programs, logic and protocols are not modified.
No. Operational data reaches the business on a defined, one-directional route for the data that must flow, rather than over continuous two-way connectivity.
Engineering and maintenance access opens for a scheduled window, for a named person, and closes automatically, rather than as standing access through shared jump hosts.
No. This page agrees which crossings exist and which should stop being permanent. CP-04 Enforce Physical Segmentation carries the zone architecture, the enforcement points and the deployment sequence.

CP-04 Enforce Physical Segmentation shows how zones are separated in hardware and how approved crossings are governed.