RAM² attack simulations need an uncertainty envelope

State the question and premises before reading the path

A nonintrusive attack simulation is a conditional analytical result, not an attempted compromise. Define the question first: the starting position, target function, represented adversary capability, knowledge level, credentials or trust already held, time available, permitted transitions, stopping rule, process operating mode, and consequence definition. Retain the simulation engine and rule-set version, run identifier, run time, and declared scope so reviewers know which analytical claim the output actually answers.

Make premises visible beside the result. A path that begins with privileged remote access answers a different question from one that begins on an external network. A model that treats a defensive control as always effective differs from one that assigns conditional failure. Record how segmentation, authentication, trust relationships, safety layers, redundancy, human intervention, and recovery are represented. A path ranking without these premises compresses the most decision-relevant uncertainty into an unexplained score.

Publish modeled and unmodeled path classes together

Create a coverage matrix for pathway classes rather than reporting only discovered routes. Include routed and switched communications, vendor and employee remote access, wireless, removable media, engineering laptops, portable tools, maintenance connections, shared services, physical access, manual operations, temporary links, failover states, and paths that exist only during startup, shutdown, upset, or emergency conditions. For each class, state whether it is fully represented, partly represented, represented by proxy, intentionally excluded, or unknown.

Maintain an unmodeled-path register with the reason, affected areas, expected consequence of omission, planned analytical treatment, and accountable reviewer. Some omissions follow from inaccessible evidence; others reflect a modeling boundary or unsupported pathway type. Those categories should not collapse into not found. The denominator matters: ten simulated routes out of ten represented classes supports a different statement from ten routes found while several plausible classes remain outside the model.

Express uncertainty as ranges and sensitivities

For every reported route or risk measure, identify uncertain transitions and consequence mappings. Where probabilities are assigned, document their interpretation and basis; where only ordinal judgments exist, do not display them as calibrated likelihood. Show how results change when attacker capability, trust, defensive-control behavior, process mode, path availability, or consequence severity moves across a defensible range. A single number should not conceal a wide result envelope.

Separate uncertainty caused by incomplete scope, uncertain transition behavior, uncertain consequence, and computational approximation. Report stable findings that persist across tested values, fragile findings that disappear with small changes, and indeterminate areas that the model cannot resolve. If several paths share one uncertain premise, show the common dependency rather than treating the outputs as independent evidence. Correlated uncertainty can make a long path list look more diverse than it is.

Test the model by withholding a plausible route

A buyer test should define a bounded industrial environment with alternate communications, remote access, a maintenance laptop, a transient operating mode, and a manual fallback. Run the model with all represented classes, then deliberately withhold one plausible route and vary one defensive transition and one consequence rule. Confirm that the coverage matrix exposes the omission, the uncertainty envelope widens, shared dependencies remain visible, and conclusions change only within the declared analytical logic.

OT Defense Review reviewed ANDRITZ's registered RAM² page on September 17, 2026. It supports the provider's current statement that RAM² offers nonintrusive breach and attack simulation through a digital-twin approach. It does not establish any site's modeled-path completeness, attacker capability, defensive-control behavior, exploitability, compromise, consequence, calibrated probability, simulation accuracy, risk level, safe operation, or security outcome.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.