Consequence-driven OT Risk (CCE) Guide

Likelihood-based risk registers struggle in OT because a determined adversary makes the worst case far more likely than any historical data suggests, and the worst case is physical. Consequence-driven Cyber-informed Engineering (CCE), developed by Idaho National Laboratory, flips the question: assume the network will be penetrated, identify the few process functions whose manipulation would be catastrophic, and engineer those consequences out. Cyber-Informed Engineering (CIE), set out in the US Department of Energy's National CIE Strategy, is the broader discipline that CCE puts into practice. This guide explains the four CCE phases, the twelve CIE principles, how the method complements IEC 62443 risk assessment, and how to run it in a real plant. It is written for OT security leads, control and process safety engineers, and risk owners in critical infrastructure.

Key takeaways

Start from consequence, not vulnerability. CCE begins by ranking the events the organisation could not tolerate, then works backwards to the systems and paths that could cause them.
Assume compromise. INL's starting assumption is that a skilled, determined adversary can and will penetrate the network, so the method looks for protections that do not depend on keeping them out.
Engineering controls beat IT controls for the worst cases. Mechanical limits, hard-wired interlocks, analogue protection and removing unnecessary digital paths can make a consequence impossible rather than merely harder.
Four phases, one year. DOE describes CCE as a year-long engagement in four phases: Consequence Prioritization, System-of-Systems Analysis, Consequence-Based Targeting, and Mitigations and Protections.
CCE complements, it does not replace. Use CCE for the handful of unacceptable consequences and IEC 62443-3-2 zone risk assessment and good hygiene for everything else.

What CCE and CIE are

The National CIE Strategy, released by DOE in 2022 at Congressional direction, defines CIE as building cybersecurity into how physical systems are conceived, designed, developed and operated, so that engineers can "engineer out" cyber-enabled attack paths early, when low-cost measures are most effective. The strategy is organised around five pillars: Awareness, Education, Development, Current Infrastructure and Future Infrastructure.

CCE is described in the strategy as a methodology developed by INL, with support from DOE and DHS, that implements CIE concepts to identify and mitigate potential catastrophic effects of cyber-enabled destruction or disruption. It assumes a sophisticated adversary will compromise the organisation, then concentrates on which functions could cause critical impact if manipulated. The background text for the method is Countering Cyber Sabotage by Andrew Bochman and Sarah Freeman, which INL lists as background reading.

Aspect	Conventional OT risk assessment	CCE
Starting point	Assets, threats and vulnerabilities	Unacceptable consequences to the mission
Likelihood	Estimated and multiplied with impact	Largely set aside: a capable adversary is assumed
Scope	Broad, every zone and conduit	Deep, a few high-consequence events
Typical outputs	Security level targets, control gaps, risk register	Engineering changes that remove or bound consequences
Who leads	Security team with engineering input	Engineers and operators with security input
Best for	Programme-wide baseline	Crown jewel functions and safety-critical processes

The four CCE phases

Phase 1: Consequence Prioritization

Leadership and engineering identify the events that would end the organisation's ability to deliver its mission: for example, sustained loss of supply to a region, an uncontrolled release, destruction of long lead time equipment, or loss of a safety function. Each is scored on criteria the organisation agrees, such as safety impact, area affected, duration, cost and recovery time.

Output: a short list of high-consequence events, each described as a physical outcome rather than as a cyber event.
Tip: phrase events as "the adversary causes X" rather than "system Y is compromised", so the analysis stays focused on outcome.

Phase 2: System-of-Systems Analysis

The team maps everything needed to cause, detect and recover from each event: controllers, safety systems, protective relays, HMIs, engineering workstations, networks, people, vendors, remote access, spare parts and the information about them. The point is to see the system as an adversary would, including the paths that are not on the network diagram.

Output: functional and data flow diagrams, an inventory of digital dependencies, and the engineering information an adversary would need.

Phase 3: Consequence-Based Targeting

The team works through how an adversary would achieve each event: the access, knowledge, capability and timing required. INL describes this as a "think like the adversary" approach and associates it with a kill chain workflow. The aim is to identify the critical paths and the points where they can be broken, not to write exploits.

Output: attack paths for each high-consequence event mapped to ATT&CK for ICS behaviours such as Modify Program (T0889), Modify Parameter (T0836), Manipulation of Control (T0831) or Loss of Safety (T0880), with the information and access each requires.

Phase 4: Mitigations and Protections

The team designs mitigations that remove or bound the consequence, preferring engineering changes over monitoring. Where a risk cannot be engineered out effectively or affordably, DOE points to its complementary CyOTE programme, which focuses on detection.

Output: a prioritised plan of engineering, procedural and detection changes, each tied to the event it addresses.

The twelve CIE principles in practice

The National CIE Strategy lists twelve principles in two groups. The table gives a practical OT example for each.

Principle	Group	Example in an OT plant
Consequence-Focused Design	Design and operational	Design reviews start from the high-consequence event list
Engineered controls	Design and operational	Mechanical overspeed trip, pressure relief valve, hard-wired interlock
Secure information architecture	Design and operational	Zones and conduits, one-way data flows for monitoring data
Design simplification	Design and operational	Remove unused remote access, protocols and functions from controllers
Resilient layered defenses	Design and operational	Independent safety system with its own network and engineering station
Active defense	Design and operational	Protocol-aware monitoring tied to operator response procedures
Interdependency evaluation	Organisational	Map dependence on power, telecoms, cloud services and vendors
Digital asset awareness	Organisational	Know which "analogue" devices actually contain firmware and communications
Cyber-secure supply chain controls	Organisational	Security requirements and firmware verification in procurement
Planned resilience with no assumed security	Organisational	Manual operation procedures and spares, assuming controls will fail
Engineering information control	Organisational	Protect drawings, setpoints and logic as sensitive information
Cybersecurity culture	Organisational	Engineers trained to ask "what if this input is malicious?"

Choosing mitigations: the engineering hierarchy

CCE favours mitigations that make a consequence physically impossible or bounded regardless of what happens in software. A useful order of preference:

Preference	Type	Example	Trade-off
1	Eliminate the digital path	Remove remote write capability; replace a networked setpoint with a local one	Loses convenience or remote operation
2	Non-digital protection	Mechanical limits, relief valves, analogue protective relays (ATT&CK M0805 Mechanical Protection Layers)	Capital cost, process redesign
3	Independent digital protection	Separate safety controller with its own network and key switch	Complexity, more systems to maintain
4	Architectural restriction	Network Segmentation (M0930), Network Allowlists (M0807), one-way gateways	Can be bypassed by a sufficiently capable adversary
5	Detection and response	Monitoring for logic changes and unusual writes, operator procedures	Relies on people and timing

Small organisations: a single tabletop on the top three consequences, using the facility's own engineers, often finds a cheap engineering fix such as a local permissive or a disabled remote function.
Large organisations: run CCE per critical facility type and feed outcomes into design standards so new projects inherit the protections.
New build versus brownfield: CIE is cheapest at concept and design stage; brownfield plants rely more on layers 3 to 5 until the next major refurbishment.

Safety instrumented systems sit at the centre of many high-consequence events. See the Safety Instrumented Systems Security Guide and the Safety and Security Co-engineering Guide.

Running a CCE engagement

Secure sponsorship: an executive owner who can accept the event list and fund engineering changes.
Form the team: process and control engineers, operators, safety, OT security, IT, procurement and a facilitator with CCE experience. INL's CCE Accelerate programme is a self-guided option, and DOE describes a version with a 16-hour preparatory training and workshop.
Agree scoring criteria: safety, environmental, customers affected, duration and cost thresholds before naming events.
Run Phase 1 in workshops: keep the list to a handful of events; more dilutes the effort.
Gather Phase 2 data with care: the collected drawings and dependency maps are exactly what an adversary would want, so classify and store them as sensitive engineering information.
Run Phase 3 as structured analysis: map paths to ATT&CK for ICS and identify choke points; do not test attacks on live systems.
Prioritise Phase 4 changes: engineering fixes first, with cost, outage needs and residual risk recorded for each.
Implement through management of change: every mitigation goes through the plant's normal engineering change and safety review, with a rollback plan.
Revisit: repeat the analysis after major changes, acquisitions or new digital capabilities such as remote operations.

A worked example: chemical dosing at a water treatment works

The following is an illustrative example, not a description of a real facility. It shows how the four phases turn into concrete changes. See the Water and Wastewater Cybersecurity Guide for the sector context.

Phase	Finding
Consequence Prioritization	Event: the adversary causes sodium hydroxide to be overdosed into treated water leaving the works. Scored highest on public safety and regulatory impact.
System-of-Systems Analysis	Dosing pumps are driven by a PLC; the setpoint is writable from the SCADA HMI, from a vendor remote access gateway and from the engineering workstation. Downstream pH analysers feed the same PLC that controls the pumps. Vendor drawings with tag names sit on a shared drive.
Consequence-Based Targeting	Paths: modify the setpoint through the HMI (Modify Parameter, T0836); change PLC logic to ignore the analyser (Modify Program, T0889); use the vendor account to reach the engineering workstation. Choke points: the remote access account, the PLC's write permissions, and the shared dependence on one controller for both control and protection.
Mitigations and Protections	Size dosing pumps and the day tank so the maximum physical dose is bounded; add an independent, hard-wired high pH alarm and pump trip that does not pass through the PLC; restrict setpoint writes to a narrow engineering range enforced in logic; remove standing vendor access in favour of supervised sessions; move drawings into a controlled repository.

Note how the most effective changes are physical and architectural. Monitoring for setpoint writes is still worth adding, but the hard-wired trip and the bounded pump capacity mean the event can no longer reach the public even if every digital layer fails. That is the core idea of CCE: decide which outcomes must be impossible, and make them so by engineering.

The example also shows why the engineering team must lead. Only process engineers know the maximum safe dosing rate, whether a pump can be resized without affecting normal operation, and which alarms operators actually trust. A security team working alone would likely have proposed a firewall rule and an EDR agent, which address the path but leave the consequence intact.

Where CCE fits with IEC 62443 and NIST

Framework	Reference	Relationship to CCE
IEC 62443-3-2	Zone and conduit risk assessment	CCE events inform worst-case consequence and target security levels for the zones involved
NIST CSF 2.0	GV.RM-01, ID.AM-05, ID.RA-04, ID.RA-05	Risk objectives, asset prioritisation by impact on mission, impact identification
NIST SP 800-53 Rev. 5	RA-3, RA-9, CP-2(8), PM-11, SA-8	Risk assessment, criticality analysis, critical asset identification, engineering principles
NIST SP 800-82 Rev. 3	OT risk management and architecture	OT-specific controls for implementing chosen mitigations
MITRE ATT&CK for ICS	T0831, T0836, T0880, T0889; M0805, M0807, M0930	Language for Phase 3 paths and Phase 4 mitigations

See the IEC 62443-3-2 OT Risk Assessment Guide for the zone-level method that CCE sharpens.

Where identity fits

Phase 3 almost always finds that the critical path runs through an identity: a vendor remote access account, a shared engineering login, a service account on the historian that can write to controllers, or a hardcoded credential in a device. Removing standing access, requiring approval and MFA for engineering sessions, and eliminating write-capable service accounts are cheap mitigations that break many paths at once. See the Identity for OT Environments Guide and the OT Remote Access Guide.

Detection and measurement

Monitor the paths Phase 3 found: logic downloads, setpoint writes and safety system mode changes on the systems tied to each high-consequence event.
Events covered: percentage of high-consequence events with at least one engineering mitigation implemented.
Non-digital protection: number of events where the consequence is bounded by a non-digital control.
Path reduction: number of identified attack paths closed since the analysis.
Information control: percentage of sensitive engineering documents with access controls and an owner.
Currency: months since the event list and system-of-systems map were last reviewed.

Common failure patterns

Too many events: a list of thirty "high-consequence" events becomes another risk register and nothing gets engineered.
Security-only teams: without operators and process engineers the system-of-systems map misses the real dependencies.
Stopping at monitoring: Phase 4 recommends more detection when a mechanical or design change was available and cheaper over the asset's life.
Leaking the analysis: the CCE output is a target package; storing it on a shared drive undoes the work.
Reintroducing likelihood by the back door: teams discard a catastrophic event because "nobody would bother", which is exactly the assumption CCE asks them to drop. Record the reasoning if an event is removed, and have the executive owner accept it.
Ignoring digital content in "analogue" devices: smart transmitters, variable speed drives and protection relays contain firmware and configuration interfaces, so a protection assumed to be non-digital may not be. Verify each claimed independent layer physically.
One-off exercise: a plant adds remote operation two years later and nobody revisits the events.

Practitioner checklist

Name an executive owner and agree consequence scoring criteria.
Write a short list of high-consequence events as physical outcomes.
Map every system, person, vendor and information source each event depends on.
Trace adversary paths to each event using ATT&CK for ICS, without testing on live systems.
Prefer mitigations that remove digital paths or add non-digital protection.
Pass every mitigation through management of change and safety review.
Classify and restrict the CCE working documents.
Feed results into IEC 62443 zone targets and design standards.
Review the analysis after major changes and at least every few years.

Consequence-driven OT Risk (CCE) Guide: Engineering Out the Worst Outcomes