Industrial cybersecurity has spent years getting better at seeing what is happening inside networks. We have more asset discovery, monitoring, segmentation, vulnerability management and detection capability than ever before.
That visibility matters.
But once a cyber incident begins affecting an operational environment, another question becomes more important:
What happens to the physical process when we can no longer trust the digital systems controlling it?
That is where cybersecurity becomes a resilience problem.
For an industrial operator, detecting that a controller, engineering workstation or remote-access connection has been compromised is only part of the problem. The operational question is whether the plant, pump, relay, drive, valve, conveyor or safety system can continue operating within acceptable limits.
If it cannot, what prevents the cyber incident from becoming a physical event?
Answering that requires understanding more than which assets are connected to a network. We need to understand what those assets actually do, what depends on them and, importantly, what is really there in the field.
An Asset Inventory Is Not a Dependency Map
Modern industrial environments depend on interoperability.
Sensors communicate with controllers. Controllers connect to supervisory systems. Gateways translate protocols. Engineering workstations configure equipment. Remote-access systems allow vendors and engineers to support systems hundreds or thousands of miles away.
None of this is inherently a problem. It is how modern industrial operations work.
The problem is that interoperability can create dependencies that are not obvious from an asset inventory.
Equipment from several manufacturers may still rely on the same software library, protocol implementation, engineering workstation, gateway, identity service or remote-access platform. What appears to be technology diversity at the equipment level may therefore contain a common point of failure underneath it.
The same is true across sites. Two plants may be geographically separated and operate different equipment yet still depend on the same service provider, engineering architecture, update mechanism or cloud service.
That is why I make a distinction between knowing what assets you have and understanding what they depend on.
An inventory might tell me that a PLC exists. It does not necessarily tell me what can configure it, what communicates with it, what physical function depends upon it or what happens to that function when the PLC can no longer be trusted.
There is another complication.
Industrial systems change.
Contractors replace equipment. Temporary configurations have a habit of becoming permanent. Communications equipment gets added. Firmware changes. Remote-access pathways appear. Drawings are not always updated.
Eventually, what we think is installed and what is actually installed can become two different things.
Sometimes the first time we discover the difference is when something fails.
We Already Have People Looking at the Infrastructure
There is a potentially valuable source of information that we do not make enough use of.
People are physically entering these environments every day.
Electricians open cabinets. Technicians service instrumentation. Engineers commission machinery. Maintenance personnel repair pumps and generators. Contractors replace equipment. Operators test protection systems.
They are not cybersecurity analysts, and we should not expect them to become cybersecurity analysts.
But they can see things.
Someone standing in front of a cabinet can tell whether the equipment recorded in an inventory is actually there. They can see whether communications equipment has been added, whether an enclosure is damaged, whether water has entered, whether a physical configuration matches a drawing or whether the manual fallback everyone assumes exists is actually present.
The task does not need to be complicated:
Recognize. Record. Classify. Escalate.
We do not need the person in the field to diagnose a cyber vulnerability. We need a reliable way of capturing what that person sees and comparing physical reality with what the organization believes to be true.
Done consistently, normal inspection and maintenance activity begins producing another form of resilience evidence.
The infrastructure already has eyes.
We need to teach them what to see.
Presence Is Not the Same as Resilience
This is where an idea I call the Nana Equation enters the picture.
It began with a much more human observation:
Presence has value before absence proves it.
The same principle applies surprisingly well to industrial resilience.
A backup system does not provide resilience simply because someone installed it. A manual fallback is not useful merely because it appears in a procedure. An independent protection mechanism is only independent if it remains independent when the primary system fails.
So I think about resilience through five factors:
Presence × Awareness × Verification × Recovery × Time = Resilience Value
Presence: Is the capability actually there?
Awareness: Do we understand what depends upon it?
Verification: Have we demonstrated that it works?
Recovery: Can it support recovery or safe degradation?
Time: How long can that capability remain available during the disruption?
If any of those assumptions are wrong, the resilience we thought we possessed may look very different during an actual incident.
There is a connection here with Zero Trust, although perhaps not in the way we normally apply the term to OT.
Instead of assuming that a controller, HMI, network connection, vendor, safeguard or manual process will be available when needed, we verify the capabilities that matter.
For critical physical functions, the objective should be straightforward:
Reduce the number of unverified assumptions.
Start With What Cannot Be Allowed to Fail
One way to approach this is to start with the physical process rather than the network.
What actually has to continue?
It might be pressure control, cooling, lubrication, electrical protection, water flow, ventilation, temperature control, emergency power or simply the ability to reach a safe shutdown state.
Then add time.
How long can we lose that function before the consequence changes?
Five seconds is a very different engineering problem from five hours.
From there, trace the dependencies supporting that function. That may take you through sensors, controllers, firmware, engineering workstations, gateways, communications pathways, identity infrastructure, remote access, power, cooling, service providers and, ultimately, people.
This exercise can expose dependencies that are easy to miss when looking at individual assets.
Then assume some of the digital controls are gone.
The HMI cannot be trusted.
Remote access is unavailable.
A controller is behaving unpredictably.
The network is down or potentially hostile.
What is left?
Maybe there is independent sensing. Perhaps there is hardwired protection, a mechanical limit, local control, analog indication, physical isolation or a manual operating procedure.
The point is not that every industrial process requires layers of expensive redundant protection.
The point is to determine where the consequence justifies independent protection and then verify that the protection we are relying upon actually works.
Engineer to Fail Soft
This brings us to an objective I believe deserves much more attention in industrial cybersecurity:
Fail Soft.
Fail Soft does not mean preventing every cyberattack.
It means designing an industrial system so that the loss of digital trust does not automatically become the loss of physical control.
If the primary digital environment becomes unavailable or untrustworthy, can the process continue safely?
Can it move into a controlled degraded state?
Can operators retain enough independent information to make decisions?
Can essential functions continue long enough to recover?
Can the system prevent a compromised controller from turning into damaged equipment, environmental release, prolonged outage or human injury?
That is a different design objective from perfect cybersecurity.
It accepts that digital controls can fail while refusing to accept that their failure must become a physical catastrophe.
And once again, people in the field become important.
Existing inspections and maintenance activity can help verify that safeguards remain present, configurations have not drifted and remediation has actually happened.
A single observation gives us a snapshot.
Repeated observations begin to tell us whether resilience is being maintained over time.
We may not need an entirely new inspection workforce to accomplish this.
In many cases, the people are already standing in front of the equipment.
The Shared Dependency Problem
There is another reason this matters.
Industrial cyber risk does not necessarily respect the geographic boundaries we traditionally use when thinking about physical risk.
A common software component, protocol, engineering platform, identity service or remote-access architecture can connect equipment in different facilities, different regions and sometimes different sectors.
Several dependencies can overlap.
A shared component sits inside a common protocol.
That protocol operates through a common engineering environment.
That engineering environment supports multiple facilities.
Those facilities may support other infrastructure that depends upon them.
Suddenly the issue is no longer one vulnerable device.
It is a failure domain nobody realized was shared.
We are accustomed to thinking about concentration geographically: facilities exposed to the same flood, hurricane, earthquake, wildfire or regional power event.
Cyber-physical concentration can be technological.
And technological concentration can cross geography.
This is increasingly important not only for industrial operators but also for the financial systems standing behind them.
Insurers may believe they have diversified exposure across manufacturers, facilities, insureds and territories while those risks quietly converge around the same technological dependency.
That is where engineering consequence becomes financial consequence.
It is also where I believe we need much stronger communication among engineering, operations, cybersecurity, risk management and insurance.
From Human Presence to Financial Resilience
My interest in the Nana Equation grew from trying to connect four things that are too often considered separately:
human presence, industrial resilience, engineering consequence and insurance exposure.
The connection is becoming increasingly important.
If we can verify what is actually installed, understand what it depends upon, determine what happens when those dependencies fail and demonstrate that independent safeguards are present, we have something much more valuable than another cybersecurity inventory.
We have evidence.
That evidence can improve engineering decisions.
It can improve operational resilience.
It can improve estimates of physical consequence.
And ultimately, it can improve how residual risk is understood, financed and transferred.
The field technician does not need to calculate the financial consequence.
The engineer does not need to become an insurance underwriter.
The underwriter does not need to become a controls engineer.
But they increasingly need to be looking at the same dependency chain.
We Are Not Trying to Create Perfect Cybersecurity
None of this removes the need for traditional cybersecurity controls.
Segmentation, secure remote access, access control, system hardening, monitoring, vulnerability management, detection and incident response all matter. They reduce the likelihood of compromise and can limit how far an attacker gets.
But industrial resilience cannot depend on the assumption that those controls will always work.
At some point we have to ask the less comfortable question:
What happens when they do not?
Can the process continue safely?
Can it move into a controlled degraded state?
Can operators still see enough to make decisions?
Can the organization recover without allowing a digital compromise to become equipment damage, environmental impact, extended production loss or a safety event?
Those questions cannot be answered by the cybersecurity team alone.
They require engineering, operations, maintenance, safety, cybersecurity, risk management and the people who physically interact with the infrastructure to develop a common understanding of what must continue, what it depends upon and what happens when those dependencies disappear.
Human presence will not replace network monitoring, automated asset discovery or engineering analysis.
It does something different.
It helps us test whether the digital representation of an industrial environment still matches physical reality.
If we connect that presence with structured observation, dependency mapping, consequence analysis and tested recovery capability, we end up with something much more valuable than another inventory.
We begin building evidence that the resilience we think we have is actually there.
And that may be the larger lesson behind the Nana Equation:
Presence has value before absence proves it.
Because the worst possible time to discover that a safeguard, fallback or the person capable of using it existed only on paper is when you need it.
