Which OT Cybersecurity Risks Should You Address First?

Start with the operating outcomes you cannot accept, trace the digital and human dependencies that could produce them, and establish which exposure paths and protections actually exist. Prioritize supported consequential scenarios and decision-changing uncertainties. Assess the safety and feasibility of each proposed intervention separately before authorizing it. A vulnerability score alone cannot tell you which plant-level action should come first.

An industrial assessment can produce a long list of technically correct findings while leaving the owner unable to decide what matters. A severely vulnerable reporting server, an overprivileged engineering account and an undocumented maintenance connection are different kinds of evidence. Ranking them requires a relationship to the process, its operating modes and its protection arrangements.

I would make that relationship the central deliverable. This paper proposes a method for prioritizing scenarios and the evidence needed to resolve them. It draws on twelve authoritative original sources and an explicitly fictional example. It is not a plant assessment, a safety case, a validated numerical scoring model or permission to test production equipment.

Decide what the assessment is allowed to conclude

The first boundary is the decision itself. Are you choosing where to investigate, selecting a near-term protective action, allocating engineering effort or approving a production change? These decisions use some of the same evidence but require different confidence and authority. An assessment can establish that a condition deserves urgent attention without establishing that a particular patch is ready to deploy.

Define the operating function, responsible owner, system boundary, relevant modes and period covered. “Assess the factory network” is too broad to make every conclusion interpretable. “Assess loss or unauthorized alteration of the dispatch function, including its maintenance and recovery dependencies” identifies a bounded task. The scope must still permit expansion when a shared dependency crosses the initial boundary.

Separate five records: the observed condition, the consequence scenario, the evidence supporting that scenario, the response options and the decision. A scanner finding belongs in the first record. It becomes evidence about a consequential scenario only after applicability, relevant access and operational effect have been examined. Keeping the records separate prevents a severe technical finding from acquiring an unsupported plant consequence through repetition.

NIST's risk-assessment guidance recognizes incomplete knowledge, undiscovered vulnerabilities and unrecognized dependencies as sources of uncertainty. It recommends communicating that uncertainty in the assessment result (Joint Task Force Transformation Initiative, 2012, §2.3.1). I would therefore allow an assessment to conclude “priority unresolved pending this specific fact,” provided it also identifies an owner and a timely way to resolve it.

Begin with the process loss, then investigate its causes

Ask operations and engineering to describe unacceptable outcomes in terms they can challenge. Loss of a service, loss of visibility, incorrect control, damaged equipment and inability to recover are not interchangeable. Identify the affected operating function, the duration or extent that matters, and the assumptions that connect the event to harm. Avoid declaring a safety consequence solely because a device sits in an industrial network.

The consequence should be specific enough to distinguish plausible paths. A process might continue safely without one supervisory display but require an orderly stop if another source of information disappears. Whether that distinction is true depends on the actual design and operating procedure. The assessment should obtain that evidence rather than importing an assumption from a similar installation.

Idaho National Laboratory's consequence-driven cyber-informed engineering approach begins by considering a determined adversary's penetration and focuses on safeguarding critical functions through engineering strategies (Idaho National Laboratory [INL], n.d.). I use that perspective to challenge dependence on perimeter success. The proposed assessment here is not represented as a complete CCE engagement or a reproduction of INL's methodology.

Consequence-led thinking is also not an instruction to start with an unlimited catastrophe. A scenario should state the conditions required for the consequence and identify which are established, assumed or disputed. If every asset receives the worst imaginable consequence regardless of its function, the assessment has discarded the distinctions it needs for prioritization. Engineering evidence must constrain the story.

Trace criticality in both directions

From the operating function, work downward through systems and components. Then work upward from a shared component to the functions that depend on it. The second pass can reveal significance that a device-by-device inventory misses: a modest management service may support several operating areas, while an expensive server may have a narrow and recoverable role.

NIST's Criticality Analysis Process Model combines top-down identification of critical processes and supporting components with bottom-up analysis of component effects and dependencies (Paulsen et al., 2018, §2.2). The important application is the change in viewpoint. A component's product category or purchase price is not a sufficient account of its importance to the operation.

Record what each relationship means. A network connection might carry process measurements, maintenance traffic, authentication, configuration changes or an administrative service. Those edges have different consequences when unavailable or misused. A diagram that shows only cables or IP subnets cannot establish all of them. I would annotate the relationships needed for the scenario rather than attempting an elaborate drawing with no decision purpose.

NIST's business impact analysis guidance connects criticality and sensitivity to consequences for organizational objectives and explicitly addresses interdependencies (Quinn et al., 2025, §§2.5–2.6). That supports examining integrity and confidentiality as well as availability. In OT, an apparently available function can still be unsuitable if the information or commands on which it depends are wrong.

Give the inventory an evidence boundary

An assessment needs more than a list of discovered IP addresses. Record the function, owner, physical or logical location, relevant version, management arrangement and known dependencies for the assets supporting the selected scenario. Distinguish an observed property from a vendor statement or an old design document. Where those disagree, preserve the discrepancy instead of choosing whichever value makes the inventory look complete.

The joint OT asset-inventory guidance links inventory with a taxonomy based on function and criticality and describes scope, asset attributes and lifecycle maintenance (Cybersecurity and Infrastructure Security Agency, Environmental Protection Agency, et al., 2025). Its sector examples are illustrative rather than authoritative taxonomies. A local classification must reflect the assessed operation rather than borrowing a label as proof of criticality.

The collection method has its own limits. NIST explains that passive discovery depends on traffic visible at monitored locations and may miss silent devices; active discovery introduces interactions that may disturb sensitive OT equipment (Stouffer et al., 2023, Appendix E.2.2–E.2.3). Passive discovery is useful evidence, not proof that everything important has been found. Active discovery needs an operationally justified and authorized method.

I would reconcile network observations with approved drawings, configuration records, maintenance information and operator knowledge. A discrepancy such as a seasonal service absent from the capture window is an investigation item, not automatically a malicious asset or a nonexistent dependency. Record observation locations and periods so that later readers understand what the collection could and could not have revealed.

Assess the operating mode, not an imaginary constant plant

A dependency can matter differently during startup, normal operation, shutdown, maintenance and recovery. A service unused during steady operation may become essential when restoring a controller or checking a revised configuration. An assessment confined to normal production can therefore miss the conditions under which the organization is least able to absorb another failure.

For each material scenario, identify the modes in which the relevant access path is present, the affected function is needed and the credited protection is available. These are separate conditions. A maintenance connection may exist only during scheduled work; a protection arrangement may also differ during that work. The assessment needs the overlap, not three unrelated statements that each sound reassuring.

I would represent the scenario as a set of conditional relationships: in this mode, this supported path can affect this function, and these protections are expected to limit that effect. Any engineering calculation of physical consequences belongs with qualified specialists and the actual system evidence. The cyber assessment should make the assumptions visible without substituting for that analysis.

The time horizon also needs definition. A short interruption, a prolonged loss and a latent integrity change can create different decisions. MITRE ATT&CK's ICS Impact tactic includes disruption and manipulation of operations, with both immediate and longer-term effects (MITRE, 2025). It provides useful vocabulary for asking about consequences; it does not provide local event frequencies or demonstrate that a particular outcome is achievable at your site.

Keep exposure distinct from importance

A component can be critical but have tightly constrained access. Another can be easy to reach but have limited operational influence. Neither fact, by itself, completes the risk scenario. Establish who or what can interact with the component, through which path, under what authority, in which mode and with what resulting capability.

NCSC's OT architecture guidance separates asset criticality, exposure and availability constraints. It asks owners to consider connectivity, exposure periods, physical accessibility and operating requirements in a definitive record (National Cyber Security Centre [NCSC], 2025). That separation is more informative than a single “critical asset” label that leaves readers guessing whether it means important, reachable or hard to maintain.

Examine the administrative path as well as the normal data path. A restricted application connection may coexist with broader management authority through a shared service. Equally, the presence of a route does not establish that the required credentials, protocol or function are available. Keep reachability, authorization and consequential capability as different claims, supported by different evidence.

Evidence should be gathered through authorized configuration review, relevant records and appropriately designed tests. This paper does not recommend probing live industrial devices to complete a diagram. When the path remains uncertain, record the competing possibilities and identify which evidence could distinguish them. An unverified line on a drawing should not become either a confirmed attack path or an assurance that no path exists.

Use vulnerability scores for the questions they answer

CVSS describes vulnerability characteristics through Base, Threat, Environmental and Supplemental metric groups. FIRST's specification explains that organizational risk decisions also require factors outside CVSS, such as wider business and other consequences (Forum of Incident Response and Security Teams [FIRST], 2024). I would retain the vector, source and version where available, rather than carrying only the headline number into the assessment.

EPSS addresses a different question: the probability of exploitation activity in the wild over the next thirty days. Its own guidance says that it does not capture local applicability, compensating controls or resulting damage (FIRST, n.d.). An EPSS value therefore cannot be read directly as the probability that your process will fail, and its absence does not establish that an unscored condition is benign.

Before interpreting either signal, confirm the affected product, configuration and relevant function. A severity rating for a component that is not deployed in the assessed path cannot establish that path's exposure. Conversely, a privileged maintenance arrangement may warrant attention without a software defect having a CVE. The assessment must include misuse of legitimate capabilities and configuration weaknesses as well as published vulnerabilities.

The joint primary-mitigations guidance addresses public exposure, default credentials, remote access and segmentation, among other concerns (Cybersecurity and Infrastructure Security Agency, Federal Bureau of Investigation, et al., 2025). Those recommendations illustrate why a vulnerability-only inventory is incomplete. Applying any response still requires the site's operating authority and a safe execution method; a general recommendation is not an instruction to disconnect an unknown dependency immediately.

Examine the protection that makes the scenario tolerable

A claimed protective function can change the consequence analysis substantially. Ask what it detects or prevents, which conditions it covers and what it depends on. An assertion that “the safety system will handle it” is not enough to justify a lower priority unless the relevant engineering evidence supports that claim for the scenario being assessed.

The Health and Safety Executive's control-system guidance discusses protective-system independence, including shared components, utilities, environments and management arrangements (Health and Safety Executive [HSE], n.d., “Independence”). I use that general engineering principle here, not the page's historical numerical examples or older standards references as current design requirements. Independence needs a stated basis, especially where common dependencies could defeat multiple protections.

Consider a protection claim that relies on a separate device but shares a necessary service or maintenance arrangement with the affected function. Physical separation alone does not settle whether the protection remains available under the scenario. The assessment should ask the responsible engineer to identify the relevant dependencies and supporting evidence. It should not declare a common-cause failure merely because two systems share something.

Do not multiply assumed failure probabilities for protective layers simply because they appear as separate boxes. Without a defensible independence model and appropriate data, that arithmetic can produce unjustified confidence. A more honest interim result is to describe the protection that is demonstrated, the conditions it covers and the unresolved dependency that prevents stronger credit.

Prioritize scenarios without forcing every tradeoff into one number

A useful assessment can establish a partial ordering. If two scenarios concern comparable consequences and one has stronger evidence of a relevant exposure with weaker demonstrated protection, there may be a defensible reason to address it first. If the scenarios differ in consequence type, uncertainty and operational constraints, the evidence may not support a unique technical ranking.

I would first separate confirmed conditions requiring the organization's urgent response process from matters suitable for planned assessment. Next, identify consequential scenarios with supported paths and inadequate demonstrated protection. Then identify missing facts that could move a scenario into or out of that category. Routine remediation can continue in parallel where its scope and acceptance are already clear.

This is not a universal four-level severity scale. Each disposition answers a different immediate question: respond, analyze a supported exposure, resolve a decision-changing uncertainty or proceed with established work. The owner still needs to decide among competing demands. The assessment's contribution is to reveal the basis and limits of that choice, rather than hiding value judgments inside a weighted sum.

If an organization uses a risk matrix, retain the underlying narrative and the definition of each category. Categories can help communication, but assigning consecutive numbers to words does not establish a measurement scale on which multiplication is meaningful. A change from “possible” to “likely” should be supported by evidence, not by a desire to move a finding above an internal funding threshold.

A fictional assessment where the highest score is not the first decision

Consider an invented packaging operation called Rowan. It has a report archive, an engineering support service and an intermittently used remote-maintenance path. The following observations are stipulated for analysis; they are not findings from a real plant. No product, vulnerability identifier, process parameter or attack procedure is specified.

Candidate scenario	Evidence available in the example	What remains unresolved	Defensible next decision
A report archive contains a severely rated software flaw	The flaw applies; the archive's documented role is historical reporting	Whether any live operational dependency contradicts that role	Confirm the boundary and plan the applicable remediation; do not infer catastrophic process loss from severity alone
An engineering support service has broader standing authority than its stated task requires	Current configuration records establish the authority; the supported operating function is important	Which protections remain effective if that authority is misused	Prioritize the consequence and protection review; develop a bounded response with operations
A remote-maintenance route is absent from the current architecture record	Maintenance documentation identifies the service, but current use and scope are unknown	Whether the route is active and what it can affect	Resolve the path through authorized evidence collection before assigning a reassuring exposure category

The table does not prove that the support service must always be fixed first. It explains why the archive's severity rating cannot settle that decision. If further evidence shows the archive supports a critical restart activity, its scenario changes. If the maintenance route is inactive and cannot be enabled without a separately controlled process, its uncertainty can be narrowed.

Now compare two possible findings about that maintenance route. In one, it reaches only an isolated support resource. In the other, it provides consequential authority over the operating function. Those alternatives could produce different priorities. Obtaining the route's current scope is therefore decision-relevant work, even before a new control is selected. The assessment should specify what evidence would distinguish the alternatives and who can obtain it safely.

The example's original contribution is the reversal test: identify the unresolved fact that could reverse your proposed ordering. If no plausible answer would change the immediate decision, further investigation of that fact may have limited value for that decision. If the answer could change the response substantially, treat resolving it as a priority candidate. This is qualitative decision analysis, not a calculated monetary value of information.

Choose the next evidence by its effect on the decision

Evidence collection has a cost and can introduce operational disturbance. I would compare candidate investigations by the decision they can resolve, their safety and feasibility, and whether their result will arrive before the decision must be made. A detailed technical report delivered after a maintenance window may be less useful than a narrower, reliable answer available while options remain open.

For Rowan, verifying the maintenance service's approved configuration may be a suitable first investigation. Broad active discovery would not automatically be a better answer merely because it produces more records. If configuration records are stale, the next step must address that weakness through an approved method. The point is to select evidence for discriminating power and credibility, not to prefer paperwork regardless of its quality.

An investigation can have several legitimate outcomes: confirmation of the path, exclusion within a stated boundary, or continuing uncertainty. Predefine what each would mean for the next decision. Otherwise an inconclusive result can disappear into a status report and leave the original assumption unchallenged. Preserve the evidence date and observation scope so that a later change can reopen the assessment.

There is also an accountability limit. A team should not keep requesting more evidence to avoid making a difficult value judgment. When the remaining dispute concerns tolerated interruption, acceptable residual exposure or allocation of scarce engineering resources, state that explicitly. Technical investigation can clarify the alternatives; it cannot manufacture the owner's preferences or substitute for delegated decision authority.

Separate the response portfolio from permission to deploy

A high-priority scenario may have several response paths: constrain an access relationship, strengthen a protective dependency, change an operating procedure, improve detection, modify equipment or accept a time-bounded residual condition. Compare what each option actually changes in the scenario. A monitoring improvement may reduce uncertainty or response delay without preventing the initiating event; those are different benefits.

Include interactions between responses. Two actions may address the same dependency and should not each be credited with eliminating the entire consequence. Another action may improve one boundary while introducing dependence on a service that is not available during recovery. The assessment should expose these relationships before a portfolio is presented as a collection of independent benefits.

The evidence required to deploy an intervention belongs to a separate OT security-change approval decision. Urgency does not establish compatibility, rollback adequacy or safe operating behavior. Keep the scenario priority and the change-readiness decision linked, so that an unready patch prompts examination of defensible alternatives rather than an unsupported declaration that the risk has become acceptable.

Recovery claims also need their own basis. A successful file backup is not evidence that a process can be restored under the relevant constraints. The separate PLC backup-testing paper examines what offline evidence can establish and what remains for the production decision. This assessment should use that evidence at its actual scope, without treating an exercise label as proof of complete recovery.

Preserve the reasoning when the system changes

The useful assessment artifact is a traceable scenario record, not just a color on a dashboard. Record the operating function and mode, consequence boundary, supporting assets and dependencies, exposure evidence, credited protections, material uncertainties, response options and accountable decision. Include the facts whose change would invalidate the current conclusion.

Reassessment triggers should follow those facts. A new maintenance route, altered management authority, revised operating procedure or changed protective dependency can matter even if the vulnerability list is unchanged. Equally, a new vulnerability may be irrelevant to the selected scenario until applicability is established. The record should support both escalation and a reasoned conclusion that the current decision remains valid.

Measure the assessment process with bounded observations. You can report how many selected scenarios have traced dependencies, how many material uncertainties remain and which decisions have exceeded their required review dates. Those counts describe the work and its evidence. They do not estimate the probability of an incident or prove that the unexamined parts of the plant are secure.

Keep sensitive implementation details in the appropriate controlled records. Leadership can receive the consequence, decision, remaining uncertainty and required resources without distributing a detailed map of every industrial access path. The assessment should improve the organization's ability to act without turning its reporting package into an unnecessary disclosure of operational dependencies.

Counterarguments, limits and the decision worth buying

Consequence analysis can become expensive, especially in a poorly documented environment. I would begin with a small number of important operating functions and expand where shared dependencies justify it. That creates a usable assessment boundary without claiming comprehensive plant coverage. It also gives the organization an opportunity to test whether the method improves its decisions before scaling the documentation burden.

There is a second risk: dramatic scenarios can consume attention while routine exposures remain untreated. The answer is to keep consequence claims conditional and evidence-backed, and to continue well-understood baseline work through appropriate authorization. The method does not require waiting for a complete architecture model before addressing a confirmed, supportable problem. It requires clarity about what the action resolves and what it leaves open.

The sources here are guidance, specifications and technical taxonomies, not twelve independent empirical studies. They do not validate this proposed prioritization method or supply local failure rates. The fictional Rowan example demonstrates how evidence can change a decision, not how any actual facility should rank its risks. Specialist process-safety analysis, local operating knowledge and applicable requirements remain necessary where the scenario depends on them.

If your OT assessment ends with vulnerability counts but cannot explain which operating outcome each priority protects, request a focused OT risk-assessment briefing. I would scope the discussion around one critical function, its consequence paths and the evidence needed for the next decision. The useful result is a defensible order of attention, with explicit uncertainty and a separate route to safe change.