Consequence-Driven Cyber-Informed Engineering (CCE): Engineering Out the Worst Case

01Key takeaways

1. 01

   CCE is a four-phase Idaho National Laboratory methodology: consequence prioritization, system-of-systems analysis, consequence-based targeting, and mitigations and protections.

2. 02

   It is consequence-driven, not threat-driven. The work begins with the handful of outcomes that would be catastrophic, not with a list of vulnerabilities.

3. 03

   CCE assumes a capable adversary will get in, so the strongest mitigations engineer the digital pathway to harm out of existence rather than monitoring it.

4. 04

   Removing a pathway can mean replacing a software-controlled function with an analog or mechanical safeguard, or making a critical path one-way so no command can travel back to the protected process.

5. 05

   CCE complements, rather than replaces, NIST SP 800-82, ISA/IEC 62443 and CISA performance goals. It tells you where to apply those frameworks first and hardest.

02What is Consequence-driven Cyber-Informed Engineering?

Consequence-driven Cyber-Informed Engineering, usually shortened to CCE, is a methodology created at Idaho National Laboratory (INL) to protect critical infrastructure from cyber attacks that could cause physical harm. It is the applied, consequence-first expression of the broader discipline of cyber-informed engineering, which the U.S. Department of Energy formalized in its National CIE Strategy.

The core idea is to think like an adversary who has decided to cause a specific, devastating outcome, then engineer that outcome out of reach. CCE does not begin by counting vulnerabilities or cataloguing every asset. It begins by naming the few events an organization simply cannot survive, and it treats protection of those functions as an engineering responsibility rather than only an IT control.

Short version: CCE assumes the attacker gets in, identifies the outcomes you cannot accept, and engineers the digital path to those outcomes out of the system.

03Why CCE matters: high-consequence targeting

Conventional defenses are built to stop the average intrusion. They are far less effective against a patient adversary who is willing to study a plant for months and is targeting one specific physical result, such as destroying equipment, contaminating a process, or causing an unsafe release. For these threats, perfect prevention is not a realistic goal.

Frameworks like MITRE ATT&CK for ICS document how such adversaries actually operate inside operational technology: gaining initial access, learning the process, then manipulating control logic, setpoints or safety functions to produce a physical effect. CCE takes that reality as its starting point. Instead of asking how to keep every attacker out, it asks what an attacker who is already in would have to reach to cause the worst case, and how to make that reach impossible.

This is why CCE is reserved for the highest-consequence systems. Applying it everywhere would be impractical. Applying it to the handful of functions whose failure would be catastrophic is where the method earns its cost.

04Phase 1: Consequence prioritization

The first phase identifies the events that would be unacceptable to the organization, the sector or the public. These are not ordinary risks. They are the outcomes that threaten safety, mission continuity, or the survival of the enterprise, such as the loss of a generator, a turbine, or a function on which a whole region depends.

Senior leadership and engineers define these high-consequence events together, because the judgment is as much about business and mission as it is about technology. The output is a short, ruthless list, often only a handful of scenarios. Everything that follows in CCE is scoped to those scenarios, which keeps the effort focused on what truly matters rather than diluting it across every possible failure.

If the consequence would not change how the organization survives or operates, it is not a CCE-level consequence. The discipline is in keeping the list short.

05Phase 2: System-of-systems analysis

The second phase maps how the prioritized consequence could actually be produced. It documents the full system of systems behind each function: the controllers, networks, sensors, safety instrumented systems, support utilities, supply chains, vendors and people that the process depends on. The aim is a complete, evidence-based picture of dependencies, not a tidy architecture diagram.

This phase is deliberately interdisciplinary. Process engineers, control engineers, IT and OT staff and operators contribute, because no single role can see the whole chain. The analysis frequently surfaces hidden dependencies, such as a forgotten remote-maintenance link, a shared time source, or a single network path that quietly connects a safety function to the enterprise.

Functional dependencies

The process steps, control logic and safety functions that must operate correctly for the system to stay within safe bounds.

Digital dependencies

The networks, controllers, software, firmware and data flows that the function relies on, including remote and vendor access paths.

Supporting dependencies

Power, cooling, timing, supply chain and human roles whose failure or manipulation could indirectly enable the consequence.

06Phase 3: Consequence-based targeting

In the third phase, analysts adopt the adversary's perspective in earnest. Given the dependency map from Phase 2, they identify the most effective ways an attacker could actually reach and trigger the high-consequence event. This is consequence-based targeting: not enumerating every theoretical vulnerability, but finding the specific paths and information an adversary would need to achieve the outcome.

The team asks what information an attacker would need to gather, what access they would need to obtain, and what sequence of actions would convert that access into physical damage. The result is a small set of critical attack paths, ranked by how plausibly they lead to the consequence. Those paths become the precise targets for the final phase, so mitigation effort is spent where it removes the most risk.

07Phase 4: Mitigations and protections

The final phase changes the system so the critical attack paths no longer work. CCE prefers mitigations that are as close to permanent and as independent of cyber means as possible. The strongest option is not a better monitor or a tighter rule, but the removal of the digital pathway that made the consequence reachable in the first place.

• Engineer the pathway out: replace a software-controlled function with an analog, mechanical or hardwired safeguard that an attacker cannot reach over the network.
• Remove or eliminate connectivity: disconnect, air-gap or schedule the disconnection of links that exist for convenience rather than necessity.
• Make critical paths one-way: where data must leave a protected zone, use unidirectional transfer so no command can travel back toward the process.
• Add independent protection: provide a non-digital backstop, such as a mechanical relief device, that limits the consequence even if the control system is fully compromised.
• Reduce the attacker's information advantage: limit how much an outsider can learn about the design, logic and dependencies of the protected function.

The test for a CCE mitigation is strict. It should still hold if the attacker already has administrative control of the relevant network. That is why removing reachability, rather than monitoring it, sits at the top of the hierarchy.

08How CCE maps to CIE, NIST SP 800-82, IEC 62443 and CISA goals

CCE is the sharp end of a wider body of practice, and it complements existing standards rather than competing with them. CIE provides the design philosophy of engineering out cyber risk early; CCE provides a rigorous way to decide where to apply that philosophy first. The recognized control frameworks then supply the specific safeguards.

Cyber-Informed Engineering (CIE)

The DOE-backed design philosophy of building cybersecurity into engineering decisions from the start. CCE is its consequence-prioritized, applied form.

NIST SP 800-82 Rev. 3

Guide to OT security. CCE helps prioritize which systems and conduits in that guidance deserve the strongest controls.

ISA/IEC 62443

Zones, conduits and security levels for industrial automation. CCE indicates which zones protect a high-consequence function and therefore demand the highest assurance.

CISA Cross-Sector Performance Goals

A prioritized baseline of practices. CCE shows where a baseline is not enough and an engineered, non-digital safeguard is warranted.

Used together, the relationship is clear. CCE answers “protect what, first?”. The standards answer “protect it how?”. Organizations that skip the first question often spread effort thinly and leave their crown-jewel functions no better protected than ordinary assets.

09Common pitfalls when applying CCE

CCE is demanding, and teams new to it tend to make the same mistakes. Most of them dilute the method until it becomes an ordinary risk assessment with a new name.

• Letting the consequence list grow too long, so the analysis loses focus and reverts to generic vulnerability counting.
• Treating CCE as an IT exercise, without the process and control engineers who understand how physical harm is actually produced.
• Stopping at detection and response when the consequence is severe enough to justify removing the pathway entirely.
• Mapping only the obvious connections and missing hidden dependencies such as vendor links, shared services or maintenance laptops.
• Choosing mitigations that fail if the attacker has administrative access, instead of safeguards that hold under full compromise.
• Running CCE once and shelving it, rather than revisiting it when the process, the architecture or the threat changes.

10Where one-way transfer and reachability elimination fit

CCE and one-way data flow share the same logic. Both aim to remove a capability rather than merely govern it. When Phase 3 reveals that a critical attack path depends on traffic being able to travel back toward a protected process, the most durable Phase 4 mitigation is often to ensure that return path simply does not exist.

This is where unidirectional transfer becomes an engineering control rather than a network preference. A protected zone can still publish the telemetry, historian data and logs that the business needs, while the path is built so no command, session or return packet can flow back toward the high-consequence function. The reachability the adversary needed in Phase 3 is engineered out, which is exactly the outcome CCE seeks.

For teams turning a CCE finding into a concrete design, a one-way pattern such as AIRGAPNET controlled connectivity can be evaluated alongside mechanical safeguards, segmentation and scheduled disconnection. A data diode is one control among many; CCE is the method that tells you which boundary actually deserves it.

11A practical roadmap and closing thought

Most organizations do not start with a full CCE engagement. A practical path is to pilot the method on a single high-consequence function: name the unacceptable event, map its dependencies, identify the critical paths, and engineer at least one of those paths out. The lessons from that pilot then shape how the discipline scales to the rest of the estate.

The lasting value of CCE is a change in mindset. It moves the conversation from “how do we keep attackers out?” to “what is the worst they could do, and how do we make that impossible by design?” For the systems where failure is not an option, that question, answered honestly and engineered into the architecture, is the strongest protection available.

FAQFrequently asked questions

SRCSources of record