Configuration drift on the production line: the change nobody approved — PLC configuration drift manufacturing illustration for All industries
/ PLC configuration drift manufacturing

Configuration drift on the production line: the change nobody approved

Configuration drift on a production line is rarely deliberate — but the consequences are the same whether a parameter changed accidentally or maliciously. Here's how to stop it.

/ IT/OT engineers · QA / Validation· All industries

The investigation starts with a batch deviation. A fill weight is off. A vision system is rejecting units it should pass. A sealing temperature has crept outside its validated range.

The standard process begins: check the physical system, review the maintenance log, interview the operators. And then, eventually, someone looks at the PLC program — and finds that a parameter changed.

Nobody approved it. Nobody logged it. In some cases, nobody can explain when it happened or who made the change. It was just there, running silently, until it caused a problem.

Why configuration drift happens on production lines

Production lines are not static systems. They are operated, maintained, and adjusted by multiple people across multiple shifts. Engineers access PLC programs to diagnose faults. Vendors connect remotely to troubleshoot. Maintenance teams adjust parameters during changeovers.

Most of these interactions are legitimate. Many of them result in changes — some intentional, some accidental, some made in good faith to solve an immediate problem without fully understanding the downstream implications.

The issue is not malicious intent. It is the absence of automatic capture. In most industrial environments, a change to a PLC parameter leaves no trace unless the engineer who made it explicitly logs it in a change management system. Manual logging is inconsistent by nature. Under schedule pressure, it is frequently skipped.

The gap between change management and configuration control

Most manufacturing operations have change management procedures. They have forms, approvals, and documentation requirements for planned changes. What they typically lack is a mechanism to capture unplanned changes — the parameter adjusted during a fault investigation, the recipe file overwritten during a hurried changeover, the SCADA tag modified to resolve an alarm that was masking another problem.

Change management procedures operate on the assumption that people follow them. Configuration monitoring operates on the assumption that they sometimes won't — and ensures that when that happens, the deviation is captured regardless. The two are explored side by side in our OT change management overview.

The distinction matters because the regulatory and operational consequences of uncontrolled configuration change are identical whether the change was deliberate or accidental. A batch produced on an unapproved configuration is an unapproved-configuration batch, regardless of intent.

/ Change control captures intent · monitoring captures reality
Change control(planned)Continuous monitoring(actual)Approvalsnever executedApproved& capturedUnapproved driftparameter tweakedmid-fault, never logged
The batch produced on an unapproved configuration is an unapproved-configuration batch — regardless of whether the change was deliberate.
Change control lists the changes the team meant to make. Continuous monitoring records the changes that actually happened. The gap between the two is where unapproved drift lives.

What continuous monitoring actually detects

A continuous configuration monitoring system compares the live state of every in-scope system — PLC programs, SCADA tags, vision configurations, machine parameters — against a signed baseline, on an ongoing basis.

When a value drifts from its baseline state, the system surfaces it immediately: which parameter changed, on which device, from what value to what value, and when. The attribution is automatic. The record is immediate.

This is different from periodic backup-based approaches, which capture a snapshot at intervals and compare against the previous snapshot. The gap between snapshots is a window of undetected exposure. Continuous monitoring closes that window.

For regulated operations, this has a direct compliance value: every change that occurs has an automatic record. The question "when did this change?" is always answerable.

/ Related reading

More on configuration drift & production risk

Want to see this running against your stack?

A short working session with our team — we'll walk through your configuration posture and show VEM running against a controller from your environment.