The short answer
Configuration Baselines
A configuration baseline is the documented, stored, known-good configuration of each asset: the controller program and its checksum or signature, the SCADA project and its version, the server build against its hardening baseline, the firewall and switch configurations, and the firmware version and parameter set of each device. It is captured at acceptance after the system has been tested, stored under version control with the date and the person, updated only through change management when a change is approved, and compared against the live system on a schedule. A difference that matches an approved change updates the baseline; a difference that matches nothing is an unauthorized change and is treated as a potential incident until it is explained.
Key points
- The baseline is what the system is supposed to look like; without it, a change cannot be recognized as one.
- Capture at acceptance, after testing, and store under version control with date and author.
- The baseline changes only through change management; the update is the last step of every approved change.
- Compare live against baseline on a schedule, automated where the platform allows.
- An unexplained difference is an incident until explained, not a curiosity.
- Controller signatures, project versions, device configurations, firmware versions: each has a way to be compared.
What to baseline
| Asset | What is captured | How it is compared |
|---|---|---|
| Controllers and remote units | The project file, the program checksum or signature the controller reports, the firmware version, the configuration of modules and communications | Vendor compare tools, or the checksum read by the SCADA and compared with the stored value |
| HMI panels | The project file and its version, the runtime version | Project compare or version check |
| SCADA servers | The project export, the tag and alarm database, scripts, the application version | Vendor version control or a file-level compare of the export |
| Servers and workstations | The build against the hardening baseline: services, features, firewall rules, accounts, installed software, policies | A configuration audit script or a compliance tool that reports differences |
| Network devices | Firewall rules, switch configurations, VLANs, port settings, radio configurations | Text compare of the configuration export against the stored one |
| Instruments and drives | Firmware version and the parameter set: ranges, scaling, protection settings, communication addresses | Parameter export compared with the stored export; firmware version read from the device |
| Documentation | Functional description, drawings, IP schedule, the baseline records themselves | Revision numbers |
Capturing it
- 1
Wait for acceptance
The baseline is the tested, accepted configuration, not the one from the day the equipment arrived. Capture it after commissioning is signed off.
- 2
Collect
Every item in the table, from the actual live system: upload from the controllers, export from the servers and devices, read the firmware versions from the equipment.
- 3
Store
In a version control system or a controlled repository, with the date, the person, and a note that this is the acceptance baseline. The repository is backed up and included in the offline copy.
- 4
Record the signatures
Where a controller or a device provides a checksum or a signature of its configuration, record it beside the file; the signature is what can be checked without uploading the whole program.
- 5
Make it the reference
The change management process points at the repository; every change record names the baseline version it started from and the one it produced.
Comparing
The comparison is a scheduled task: monthly for most assets, weekly or continuous for the controllers that matter most. Where the platform provides tools, the comparison is automatic: a version control product uploads each controller on a schedule and compares it with the stored project, and reports differences with who and when; a compliance tool audits the server build; the SCADA reads the controller change counter or signature and alarms when it moves. Where it does not, a person exports the configuration and compares it with the stored one, which is tedious and still worth doing for firewalls, switches, and critical controllers. The output is a list of differences, each of which is one of three things.
| Difference | Meaning | Action |
|---|---|---|
| Matches an approved change record | The change was made as approved and the baseline was not yet updated, or the schedule caught it first | Update the baseline; close the change record |
| Matches an emergency change that was documented afterward | Someone fixed something under pressure and recorded it later | Update the baseline; review whether the emergency process worked |
| Matches nothing | An unauthorized change: a well-meaning edit, a vendor session nobody recorded, a mistake, or an intrusion | Treat as an incident: find who, when, and what, from logs and interviews; assess the change; revert or approve; and fix the gap that allowed it |
Keeping it alive
Baselines die when the update step is skipped: a change is made, the record is closed, and the repository still holds the old version. Within a year every comparison shows differences, the differences are all explained by memory, and the practice is abandoned. The defense is to make the baseline update the last mandatory step of the change record, checked by whoever closes it, and to run the comparison on a schedule so that a missed update is caught in a month rather than a year.
Frequently asked questions
- Is the integrator project archive a baseline?
- It is a starting point, and it is often not what is running: changes during commissioning and afterward were made online and never returned to the archive. Upload from the live system at acceptance, compare with the archive, resolve the differences, and store the result as the baseline.
- How much do version control tools for controllers cost?
- Vendor and third-party products that upload, compare, and record controller programs on a schedule are priced for plants of some size and pay for themselves at the first unexplained change. A small utility can do the same by hand for a handful of controllers with the vendor compare function and a repository, on a monthly calendar entry.
- What about setpoints operators change every day?
- Operating setpoints within their limits are operations, not configuration, and they are not in the baseline; the limits are. A setpoint changed outside its limits, or a limit changed, is a configuration change and goes through change management.
- Do we baseline the office computers that never touch the plant?
- No; the baseline covers the control system and what protects it. The engineering workstation that programs controllers is in; the manager laptop with a view-only web client is the office IT department concern, with the firewall between them.
Related topics
- Program Change DetectionKnowing when a controller program changed and whether it was supposed to: change counters and signatures the SCADA can alarm on, scheduled compares, audit logs, mode and network monitoring, what each catches, and what to do when one fires.
- Change Management for OTA change process sized for a utility control system: what counts as a change, the request with risk and rollback, owner approval, the window, backup before and verification after, the baseline update, the emergency path, and the record.
- Controller Program IntegrityKnowing that the program in the controller is the one that was approved: checksums and change counters, the scheduled compare against the trusted backup, signed and protected projects, what an unexplained difference means, and making the check routine.
- Server HardeningReducing what an attacker can do with a SCADA server: a baseline from the vendor guide and a benchmark, unused services removed, the host firewall on, application allowlisting, controlled media, separate administrator accounts, and logs sent off the box.
- 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.
- Building an OT Asset InventoryThe list of everything in the control system with a network interface or a program, and how to build one that is right: what counts, the fields to record, the site walk, the switch tables and passive listening that find the rest, and keeping it current.
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.