The short answer
Controller Program Integrity
Program integrity is the assurance that the logic running in a controller is the logic the utility approved and nothing else. It is maintained by keeping a trusted master copy of every program under version control, reading the controller program checksum or change counter into SCADA and alarming on change, comparing the running program against the master on a schedule with the platform compare tool, and treating any difference that has no change record as an incident until it is explained. Platform features such as project signing, source protection, and audit logs support it; the discipline of the compare is what makes it real.
Key points
- A trusted master under version control is the reference. Without it there is nothing to compare against.
- Read the checksum and the last-edit time into SCADA and alarm on change. That is continuous detection.
- Compare the running program with the master on a schedule. That is periodic verification.
- Every difference has a change record or it is an incident.
- Platform security features help, but the compare is the control.
Why integrity is its own concern
A controller runs whatever program it holds. A change to that program, whether by a well-meaning technician at midnight, a vendor on a support call, an integrator who forgot to record it, or an attacker, changes how the process behaves, and none of those changes leave a mark that an operator sees. The setpoints look the same, the screens look the same, and the pump starts a foot later or the chemical feed has a new maximum. Program integrity is the practice of knowing, at any time, whether the program in the controller is the one that was approved, and of finding out quickly when it is not.
The master
Integrity starts with a trusted copy: the project file as last approved, with its comments and documentation, in a version-controlled store that records who changed it and when, backed up offline. The PLC program backups page covers building that store. A utility that has only the program in the controller has nothing to compare against, and its first step is to upload, review, and establish the master.
Continuous detection
Most controllers expose values that change when the program changes: a program checksum, a change counter, a last-edit timestamp, and on some platforms a user identity for the last edit. Read them into SCADA as tags. Trend them. Alarm when they change. A checksum that changes at 2 a.m. on a Sunday with no change record is an alarm that names the controller and the time, and it is the fastest detection a utility can have. The controller mode and its restart count are read alongside, because a program change usually involves a mode change, and a program corruption often involves a restart.
| Signal | What it shows | Alarm on |
|---|---|---|
| Program checksum or signature | Any change to the program | Any change |
| Change counter | The number of edits since the program was loaded | Any increment |
| Last edit timestamp | When the last change was made | A change; compare with the change log |
| Last edit user, where available | Who the platform believes made it | A user not on the approved list |
| Controller mode | RUN, REMOTE, or PROGRAM | Any change from RUN |
| Restart and fault counters | Power cycles, hard faults, watchdog events | Any increment |
| Force count | Active forces on I/O | Any nonzero value outside a maintenance window |
Periodic verification
The checksum says the program changed; the compare says what changed. On a schedule, monthly at most utilities and more often for critical controllers, the running program is uploaded and compared with the master using the platform compare tool or a version control product built for controllers. The result is either identical, which is recorded, or a list of differences, each of which is matched to a change record. A difference with a record is a master that needs updating. A difference without a record is an incident: the change is reviewed rung by rung, the process is checked for its effect, and the program is restored from the master if the change was not approved.
Platform features that support integrity
- Project signing
- A digital signature on the project file, verified on download, so that a modified file is rejected. Available on newer platforms.
- Source protection
- Encryption or locking of routines so that the logic cannot be read or edited without the key. Protects the intellectual property and prevents casual edits; does not prevent a download of a different project.
- Controller audit log
- A log in the controller of mode changes, downloads, edits, and forces, with time and identity where the platform has users. Read it into SCADA or review it on a schedule.
- Change detection in the programming software
- A compare on every connection, with a warning if the controller differs from the open project. Useful for the programmer; not a substitute for the scheduled compare.
- Controller security mode
- A mode on newer platforms that requires authentication for downloads and mode changes and that logs them. Enable it where the platform offers it.
Building it into the routine
- 1
Establish the master
Upload, review, document, and commit every controller program to the version-controlled store. Record the checksum.
- 2
Add the tags
Checksum, change counter, last edit time, mode, restarts, and forces for every controller, into SCADA, trended, alarmed.
- 3
Write the change procedure
Every program change updates the master, records the new checksum, and is logged with who, when, and why. The alarm on the checksum change is acknowledged against the record.
- 4
Schedule the compare
Monthly for every controller, weekly for the critical ones, with the result recorded.
- 5
Define the incident response
What happens on an unexplained difference: who is called, the process check, the restore decision, and the investigation of how the change was made.
- 6
Review
Quarterly: every alarm, every compare, every unexplained difference and its resolution.
Frequently asked questions
- The checksum changes every time someone goes online. Why?
- On some platforms an online session that changes nothing still updates a timestamp or a counter; on others the checksum is stable unless the logic changes. Learn which values on your platform change only with the logic, and alarm on those. The audit log, where available, distinguishes an online session from an edit.
- What if the program in the controller is better than the master?
- That is common on a system where the integrator made a fix on site and the master was never updated. The compare finds it; the review confirms the change is wanted; the master is updated and the change is recorded after the fact. The integrity process is how the master catches up, not a reason to distrust the fix.
- Can an attacker change the program and restore the checksum?
- A checksum is not a cryptographic signature and a capable attacker with controller access could in principle craft a program with the same value on some platforms. The scheduled compare against the master catches what the checksum misses, the network controls and the keyswitch make the access itself hard, and platforms with signed projects close the gap. Layers, as always.
- How long does the monthly compare take?
- A few minutes per controller with the platform tool, longer with a manual review of differences. A version control product for controllers automates the upload and compare on a schedule and reports only the differences, which makes weekly compares of a hundred controllers practical.
Related topics
- PLC Program BackupsWhat a complete controller backup contains, how often to take one, where to keep it, why the upload from the running controller is not the master, and the verification that turns a folder of files into a recovery plan.
- Controller Mode Switch and KeyswitchThe physical switch on the front of a controller: what RUN, REMOTE, and PROGRAM mean, why most controllers are left in REMOTE and why that matters, a policy for a utility, how mode is monitored and alarmed, and what to do on platforms with no keyswitch.
- Controller HardeningWhat can be locked down on a PLC or RTU: keyswitch and mode, credentials, unused services, access lists, firmware, and the engineering workstation that is the real target.
- OT Incident Response PlanThe plan for the day the control system is not trusted: who decides, the triggers, the first hour, isolating without stopping treatment, running by hand, preserving evidence, who to notify and when, recovery from backups, and the exercise that makes it real.
- Controller Memory and AddressingHow a controller organizes its data: data tables and tags, the input and output images, the elementary data types and what they hold, and the naming discipline that keeps a program readable years later.
- Vendor Remote AccessIntegrators and equipment vendors need to get in. How to let them without leaving a permanent door open: utility-controlled sessions, named accounts, MFA, a jump host, session recording, and what to do about the modem you did not know was there.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.