octoplant Change Detection: Scheduled Jobs, Drift and Unauthorized Changes

octoplant change detection is the part of AMDT’s version control that watches the plant floor rather than the repository. Scheduled jobs upload from devices and compare what is running against the approved version. In AMDT’s words, “automated jobs compare the current device state with the stored reference version, exposing configuration drift,” and the system “alerts you to every difference” (AMDT, change management and version control).

It exists because the planned path, check-in and check-out, only governs people who follow it. This page covers how the jobs work, how to tell planned, accidental and unauthorized changes apart, the security case, tuning job frequency, and what to do when a change is detected. It sits under octoplant version control and change management.

How octoplant change detection works

AMDT describes octoplant running “scheduled jobs across your OT environment” that “capture current configurations and programs, and compare them against approved versions” (AMDT, About octoplant). In practice the loop is:

1. A job runs on schedule for a device or group of devices.
2. It uploads the current program or configuration from each device.
3. It compares the upload against the approved version using Smart Compare.
4. It records the result. A match needs no action. A difference is logged.
5. It alerts. AMDT lists “alerts and notifications for unplanned or out-of-process changes” (octoplant.com, change management), and also alerts when “backups fail, devices become unreachable, or configuration states deviate from the expected version” (AMDT, About octoplant).

The same jobs produce the backups described under automated device backup, which is why detection and backup usually share one schedule.

The first baseline decides everything after it

Change detection is only as good as the approved version it compares against. When a plant first connects devices, the obvious shortcut is to accept whatever the first upload finds as the approved version. That blesses every undocumented edit already in the plant and turns years of drift into the official reference.

A more defensible start:

• Upload first, approve later. Treat the first upload as a snapshot, not a reference.
• Compare it with whatever exists: the integrator’s handover files, the last project on the engineering server, the laptop copies.
• Resolve the differences by device, starting with safety, quality-critical and bottleneck assets, and record why each one was accepted.
• Approve only after review, so the reference means “checked,” not merely “found.”

It is slower, but it is the only way the first alert means something.

Planned, accidental and unauthorized: telling them apart

AMDT says octoplant detects “planned, accidental, or unauthorized changes” (same source). The software sees all three the same way: a difference. The classification comes from comparing the detected change with the plant’s own records.

Type	Typical example	How you recognise it	What it costs if missed
Planned	An approved change downloaded but not yet checked in	Matches a work order or change request	A stale repository; the next change starts from the wrong version
Accidental	A forced I/O bit left on, a wrong parameter after a drive swap	No record, no intent, often found by the person who did it	Quality drift, nuisance faults, a latent hazard
Unauthorized	A contractor’s unrecorded fix, a bypassed interlock, a malicious edit	No record and no plausible owner	Safety, product and security exposure

Most detected changes are planned or accidental. A night-shift technician who raises a timer to keep the line running is not an attacker. Treating every alert as a security incident burns out the people who must review them; treating none as one misses the one that matters.

An illustrative scenario. Monday’s job flags a difference on a mixer controller: an agitator speed limit raised by 10%. Step one of the triage below finds no work order. The weekend supervisor explains that a maintenance technician raised it to clear a viscous batch and meant to put it back. The controls lead restores the approved version, records why, and opens a change request to assess whether the higher limit should become standard. Total effort: twenty minutes, on a weekday, with the right people.

Drift: the slow version of the same problem

Drift is many small undetected changes over months. Each is harmless alone. Together they mean the stored program no longer describes the plant, and every planned change and every restore is built on a guess. Our manufacturing downtime guide covers how much of a long outage is spent establishing what state the equipment was in. Frequent change detection keeps drift small enough to resolve one item at a time.

Why octoplant change detection matters for OT security

An unauthorized change to controller logic is the outcome an OT attacker wants: a changed setpoint, a disabled interlock, a modified sequence. Network monitoring tools see traffic to a controller. A device-content compare sees what changed inside it. They are complementary, and we found no public octoplant integration with Claroty, Nozomi, Dragos or Armis as of October 2026; see OT security platforms.

What a device compare catches, mapped to attacker techniques. MITRE ATT&CK for ICS catalogues how adversaries change controllers, and for each technique below it lists Audit (M0947) among the mitigations: verifying the integrity of changes after the fact.

ATT&CK for ICS technique	What the attacker changes	What scheduled change detection shows	What it misses
Modify Program, T0889	Program organisation units, through downloads, online edits or program appends	The changed or added blocks against the approved version	Changes reverted before the next job runs
Modify Parameter, T0836	Values that govern behaviour, such as run times or limits	Changed parameters, where the device type’s compare covers them	Values held only in live memory and excluded from the compare as noise
Program Download, T0843	A user program transferred to the controller, in full or as an online edit or append	The resulting difference, from a few rungs to the whole program	Who did it, and from where: that is the network sensor’s evidence

The right-hand column is the case for running a network monitor as well. A compare proves the content changed; traffic records show the session that changed it.

For the evidence side, change detection records feed frameworks such as NIS2, IEC 62443 and NERC CIP. The compliance page explains what a tool can and cannot evidence. For the inventory and vulnerability view across sites, built on the same octoplant data, see octovision.

Tuning job frequency against network load

Uploading a full program puts load on the controller’s communication capacity and on the network, and some older devices and networks handle it poorly. AMDT states that octoplant licences include unlimited jobs (octoplant pricing), so the constraint is operational, not commercial.

• Tier by criticality. Daily for safety, quality-critical and regulated assets; weekly for the rest is a common starting point.
• Stagger jobs so a hundred uploads do not hit one network segment at shift change.
• Avoid sensitive windows, such as batch execution or changeovers, for devices that respond slowly during uploads.
• Respect regulatory floors. NERC CIP-010-4 requirement R2.1 asks for monitoring of baseline changes at least once every 35 calendar days on high impact BES Cyber Systems (NERC). That is a minimum for compliance, not a sensible interval for catching an edit before it causes harm.
• Match frequency to review capacity. Alerts nobody reads within a day are not detection.
• Check the network path. Jobs cross zones and firewalls; an OT network assessment and our note on segmentation in brownfield plants cover how to allow this without flattening the network.

Triage table for a detected change

Step	Question	Owner	If yes	If no
1	Is there a matching work order or change request?	Controls lead	Check in and approve as the new reference	Go to 2
2	Did someone on site make it, and can they explain it?	Area supervisor	Assess; document and approve, or restore	Go to 3
3	Was a contractor or OEM on site or connected?	Project engineer	Obtain their record; then as step 2	Go to 4
4	Does the change touch safety, quality or security functions?	Controls lead, OT security	Treat as an incident; preserve evidence	Restore the approved version and record why

Where it gets hard

• Detection is periodic, not instant. A change made just after a job runs is invisible until the next one.
• Live data noise. Values that legitimately change in operation can trigger false differences unless filtered.
• Coverage gaps. Devices octoplant cannot upload from, or that sit on unreachable networks, are not checked at all. Confirm coverage against AMDT’s gated support matrix.
• Alert fatigue. Without a triage owner and a time limit, alerts accumulate and the system quietly stops working.

Back to octoplant version control and change management or the AMDT hub.