An Octave deviation is not an unauthorized OT change

A baseline comparison observes difference, not authority

Octave's official product record describes native configuration backups and a baseline used to identify deviations. That can give defenders valuable evidence across isolated or transient industrial assets. The provider also uses the phrase unauthorized changes. Operational authorization, however, may reside in an engineering change, maintenance order, emergency procedure, vendor service instruction, commissioning record, or approved temporary deviation that a comparison engine cannot infer from file difference alone.

Create a deviation-review record that links the observed asset and configuration object to the backup identifier, collection method, source and target versions, hash or comparison result, observation time, baseline version, change window, change request, responsible engineer, operator awareness, vendor or integrator role, expected process effect, validation method, exception, and disposition. Preserve unknown identity rather than attributing the change from timing or network adjacency.

Define known good as an approved and effective state

Known good should not mean merely old, common, last collected, or free of a published vulnerability. A usable engineering baseline identifies the exact asset or population, hardware and firmware context, configuration scope, approved owner, effective date, operating mode, dependencies, safety and reliability assumptions, required companion files, verification method, and supersession history. The current running state may legitimately differ during startup, testing, maintenance, failover, or controlled recovery.

Collection quality also changes meaning. A backup can be incomplete, taken from the wrong controller, normalized by a tool, generated while changes are pending, or unable to represent transient logic and runtime values. Record unsupported objects, access limitations, collection failures, timestamps and clock bases, transformations, and the compatibility matrix used. A clean comparison cannot prove full coverage, while a difference can be a data artifact rather than a device change.

Separate detection, investigation, and operational disposition

A deviation alert begins triage. It does not authorize an analyst to connect, scan, patch, restore, block, isolate, or otherwise change a live system. Investigation should bring security, control engineering, operations, maintenance, safety, reliability, and the relevant product supplier or integrator into the decision according to site procedures. The record should identify which role can classify the difference and which role can authorize any operational response.

Test benign and consequential cases in an authorized non-production or otherwise site-approved context: a scheduled logic change, a firmware upgrade, a temporary bypass, a replacement device, an emergency adjustment later regularized, a failed write, a backup after failover, a local action during a remote session, and an unexplained difference. Each should preserve the original evidence, later explanation, decision, verification, and any return-to-approved-state record without silently rewriting the baseline.

Verify the evidence chain without exposing sensitive detail

A buyer demonstration should use synthetic or non-sensitive configurations and show collection, versioning, difference detection, approval correlation, reviewer disposition, escalation, and recovery evidence. Ask how the product treats unreachable assets, partial files, duplicate identities, vendor-specific encodings, clock drift, deleted objects, and baseline changes. The publication does not reproduce configuration values, operational commands, network locations, credentials, or restoration steps because those details could increase misuse or operational risk.

OT Defense Review reviewed the registered Octave Cyber Integrity page on September 5, 2026. The page supports the documented product functions and name lineage, but it does not establish any site's coverage, collection safety, baseline adequacy, authorization mapping, alert accuracy, process effect, remediation, recovery, compliance, safety, reliability, or outcome. This is clean current-source analysis, not a verified post-cutoff incident or release report.

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.