A
State
What operating condition must exist? Pressure, temperature, speed, level, concentration, orientation, charge, or another state variable.
The methodology
Start with the consequence.
Do not begin with the attacker, the vulnerability, or the security tool. Begin with the thing that must not happen. Then work backward until you can see what has to be true for it to happen—and what you can change so that it cannot.
Consequence-first engineering for cyber-physical systems
01 / Define
Name the consequence precisely.
“Cyberattack,” “system compromise,” and “loss of resilience” are not consequences. They are abstractions. A useful analysis names the physical, operational, financial, or mission outcome that actually matters.
The question is: What are we trying to prevent?
A consequence is something the system does—or becomes—that crosses a boundary you care about.
Examples include contamination, uncontrolled energy release, collision, loss of containment, equipment destruction, unsafe pressure, or loss of a critical function.
02 / Bound
Define where the consequence actually occurs.
Once the consequence is named, define the system boundary. What equipment, people, processes, environments, dependencies, and external conditions are relevant to producing—or preventing—it?
This prevents the analysis from becoming an exercise in describing an entire enterprise. The useful unit is the portion of the system that determines whether the consequence crosses its boundary.
Normal state → boundary → unacceptable state
Boundaries may be physical, functional, quantitative, geographic, temporal, or operational.
The threshold should be explicit enough that two engineers can look at the same system and agree on whether it has been crossed.
03 / Decompose
Find the ingredients.
A catastrophic outcome generally requires some set of conditions to exist simultaneously. Those conditions may involve energy, material, geometry, timing, state, control actions, dependencies, or human actions.
The analysis works backward from the consequence: What physically has to happen for the system to cross the boundary?
B
Energy / material
What must be added, removed, redirected, released, accumulated, or allowed to continue?
C
Interaction
What has to interact with what—and under what geometry or timing—for the consequence to occur?
Cyber may be the initiating mechanism. The consequence still has to obey the system’s physics.
04 / Distrust
Stop assuming the digital layer will save you.
CIE explicitly asks engineers to consider the consequences of cyber manipulation and to identify engineering controls that can eliminate or reduce those consequences.
That changes how safeguards are evaluated. A sensor, PLC, network path, HMI, software interlock, vendor connection, or automated response may be useful—but when an adversary can manipulate it, it should not silently become the only thing standing between the system and catastrophe.
The design question
What happens when the thing you trusted is no longer trustworthy?
That is not a reason to abandon digital controls. It is a reason to make the consequences of their failure bounded, recoverable, and—where practical—physically impossible.
05 / Deny
Change the system, not just the alert.
Engineered controls are the central design opportunity: physical logic, physical constraints, redundancy, passive dynamics, one-way enforcement, fail-safe defaults, resilient algorithms, and other mechanisms that directly constrain system behavior.
Physical constraint
Limit it.
Make the dangerous quantity, force, pressure, speed, or energy unavailable at the required magnitude.
Redirection
Send it somewhere safer.
Change the path of energy, material, or system behavior so the original consequence is no longer reached.
Independence
Break the dependency.
Do not let the same compromised input, network, processor, or assumption defeat every protective path.
Degradation
Make failure survivable.
When full operation cannot continue safely, preserve the critical function in a constrained or manual mode.
The appropriate control depends on the system, the consequence boundary, and the engineering trade-offs. The method does not prescribe a single technology.
06 / Validate
Ask whether the consequence can still happen.
The final test is not “Did we add enough security controls?” It is: Can the unacceptable state still be produced?
Test the design against cyber manipulation, ordinary failures, human error, loss of automation, degraded operating conditions, and the dependencies that sit outside the system boundary. CIE and related engineering work also emphasize planned resilience, interdependencies, digital asset awareness, supply chain considerations, and lifecycle traceability.
The objective is not perfect prediction. It is a system whose most important failures are bounded by design.
Use it on something real
There is a system you already worry about.
Bring me the consequence, the design, or the problem you cannot quite make sense of. We can start by defining exactly what must not happen.
Describe the problem →