A security incident is usually told as a story about detection: how quickly it was found and contained. For industrial operations that misses the bigger story. In the incident here, the compromise was contained in roughly an hour. The recovery took a day-long IT outage. The recovery was the part that stopped the business.
The incident, abstracted
Attackers compromised a site’s core network services, DHCP and DNS. Both belonged to corporate IT, and both also served the operations floor. Within roughly an hour the IT team had isolated the affected servers. By incident-response standards, containment was swift.
On the floor it was a different story. Handheld scanners stopped getting leases and could not resolve the terminal-emulation services they depend on. Material movements stopped syncing to the cloud system of record. The record itself was healthy; every path to it simply ran through corporate IT. Local OT applications were re-pointed with static addresses for partial relief. The cloud-dependent workflows could not be rescued that way.
Then IT needed a broader hardening window: patching, credential rotation, policy checks, re-baselining. Roughly 24 hours with core services offline. For a just-in-time operation that is not maintenance. It is a missed shift, and missed commitments down the line.

Figure 1. The initial incident and the subsequent IT hardening window have very different operational consequences. The prepared-cell scenario illustrates the intended resilience benefit.
Two environments, one set of dependencies
An industrial site is two operating environments sharing one set of essential services. Corporate IT provides identity, addressing, name resolution, firewalls and internet access. OT runs the devices and workflows that move material and keep production going, and it rents those services from IT. The arrangement is efficient and auditable, which is why it is so common. It also means OT inherits IT’s blast radius without any say in when IT goes down.

Figure 2. Operational workflows depend on corporate IT services even when their cloud applications remain healthy.
Three things about this incident generalise.
Dependency, not compromise. OT was never breached. Losing the shared services was enough.
Remediation is the outage. The responsible hardening pass stopped operations far longer than the breach did. Resilience that covers only the breach covers the small event.
The revenue path is short. The system of record stayed healthy. The gap was a few hundred metres of network between a scanner and the internet. A handful of shared services along that path was enough to stop the workflow.
Think in cells, not backup links
The instinct after an incident like this is to buy a second internet connection. Necessary, not sufficient. A second pipe with no addressing, no name resolution, no identity and no policy behind it is a pipe to nowhere. Worse, it is a pipe that quietly bypasses the governance the enterprise spent years building.
The better mental model is an operational cell. Each mission-critical, revenue-impacting workflow sits inside a bounded unit built to keep running when the larger enterprise is down, under a pre-approved set of locally enforceable security and policy controls. Not an improvised degraded mode. Not an exception someone signs off at two in the morning. The same rules as yesterday, enforced locally.
One boundary matters more than any other. Losing a shared IT service is not the same as being put under security quarantine. A cell may carry a workflow through an outage; it must never use its independent path to carry one past a containment decision. The authority to keep operating is granted in advance, with explicit conditions under which the cell must stop. An outage signal lays out the safe lane. It never, on its own, opens it.
The analogy I keep returning to comes from AI. A large model’s behaviour can be distilled into a small one that runs where the large one cannot. An enterprise’s security posture can be treated the same way. The access policies, segmentation rules, compliance controls, logging obligations and SOPs that govern a workflow would be distilled in peacetime, versioned and audited into a compact, locally enforceable form that travels with the cell. When the mother estate goes dark, the cell does not improvise a policy. It already carries one.
Distillation has limits, and a good design states them. A disconnected cell cannot assume every enterprise service is still reachable, or that its local view of identity and policy is current. Some controls depend on the live estate and cannot be carried locally. Where a cell can no longer establish the security assumptions a workflow requires, the workflow restricts or stops. That is a feature, not a failure.
A cell is not the enterprise with the security turned down. It is the enterprise, distilled.
Anatomy of an operational cell

Figure 3. Conceptual operational cell: distilled governance, local critical services, health monitoring and an independent, policy-governed path to approved cloud applications. Failover remains subject to explicit security controls.
Workflow boundary. The specific devices, services and cloud endpoints that make up one revenue-critical loop. Small by design; a cell that holds everything is just a second unrestricted network.
Local critical services. DHCP scopes, local DNS resolution, terminal emulation, label and print, whatever the devices cannot live without. Provisioned and tested in advance, with clear rules for how authority transfers when the corporate services go quiet.
Distilled governance. Identity assertions, allow-lists, segmentation rules, logging and retention obligations rendered as local enforcement, not referenced from a server that may be down. Policy freshness, credential validity and the conditions that require access to stop are defined ahead of time.
Independent egress. LEO satellite, fixed wireless or a second ISP, terminated outside the corporate perimeter and pre-provisioned. It provides reachability, not a licence to bypass enterprise security decisions.
Health monitoring and governed failover. Detect the loss, redirect only permitted traffic, keep access to the system of record narrowly scoped. Authentication, session continuity and fail-back are designed and tested in advance, never improvised under fire.
Telemetry and audit. Every cutover, permitted flow and restoration is logged, so security can reconstruct what ran outside the perimeter and why. When central logging is unreachable, the cell keeps records locally and reconciles them when the estate returns.
What it does and does not promise
A cell covers a handful of workflows, not the business. Everything outside its scope stays down until IT returns, deliberately. The pattern helps with WAN faults, firewall misconfigurations and planned maintenance as much as with breaches, but the response has to fit the cause. A security incident and a network fault are not the same thing, and a quarantine is never quietly defeated by a fallback path.
It does not promise uninterrupted service under every failure. Some applications need continuous access to central identity; some sessions will not survive a network transition; a cell that cannot stand up its own security assumptions has to stop the affected work. These are constraints to design around, not reasons to abandon the idea. The goal is not to make every enterprise dependency disappear. It is to find the few workflows that must survive, understand what they depend on, and build a governed path for them before the incident, not during it.
The business case
Start with the cost of a stalled hour at the dock or on the line, times the length of the next hardening window. Set that against the cost of keeping a few cells ready. The numbers vary by site; the shape of the decision does not. The larger dividend is organisational. IT gets the time it needs to remediate properly, and operations keeps a defined, governed way to do the work that cannot wait. The enterprise stops having to choose between doing security well and keeping the lights on.
The breach was the smaller interruption. The fix was the bigger one. Build the cell before you need the fix.
Bibhuti Kar is Chief Development Officer at Ramen.




