A security configuration baseline is a documented, approved set of hardened settings that defines how a device should be configured to be considered secure. It is the known-good reference standard - the answer to what right looks like - that every matching device is compared against and that hardening aims to achieve. This page explains what a security configuration baseline is, how it differs from the act of hardening and from operational data, and why measuring devices against a baseline is what keeps a control network from quietly drifting into insecurity.
Configuration Baseline / Hardening in one line: A security configuration baseline is a written specification of the exact secure settings a class of device should have - which services are disabled, which accounts exist, how authentication is configured, which ports are closed, and so on - serving as the known-good reference against which actual devices are measured. It is the standard, not the action: hardening is the work of bringing a device up to the baseline, and comparing a device's live settings to the baseline reveals configuration drift where a device has fallen out of compliance.
Hardening a device means changing its settings to reduce its attack surface - turning off unused services, closing unnecessary ports, removing default accounts, enforcing stronger authentication. But hardening on its own raises a question: hardened to what? Without a defined target, one engineer's hardened server and another's may differ, and there is no way to say whether a given device is configured correctly. The security configuration baseline is that defined target. It writes down, setting by setting, what a properly hardened device of a given type looks like.
This makes the baseline a reference standard rather than a task. It might specify that a particular class of HMI has remote services disabled, uses named individual accounts, has a specific password policy, closes a defined list of ports, and logs to a central server. Any HMI of that class can then be checked against the specification and judged compliant or not. The baseline turns security from a matter of individual judgment into something objective and repeatable - a device either matches the approved configuration or it does not.
Well-known industry benchmarks are often the starting point for a baseline, providing vetted hardening recommendations for common operating systems and platforms. In OT, though, a baseline usually has to be tailored, because a control device cannot simply adopt every generic recommendation - some hardening steps would break the very functions the device needs to run the process. The baseline is therefore the negotiated known-good: as hardened as the device can be while still doing its job, documented so everyone agrees on what that state is.
A baseline only delivers value if devices are actually measured against it. That comparison is where the concept earns its keep. When a device's live configuration is checked against the baseline and something differs - a service that should be off is running, a firewall rule has changed, an account has appeared - that difference is configuration drift. Drift is how a system that was once secured slowly becomes insecure, one small unreviewed change at a time, often through legitimate troubleshooting that nobody remembered to undo.
Catching drift is the practical purpose of maintaining a baseline. By periodically comparing each device to its approved configuration, an operator can see exactly where reality has diverged from the standard and decide whether the change should be reverted or, if it was intentional and safe, folded into an updated baseline. Either way, the baseline stays the authoritative description of correct, and no change goes unaccounted for. This is what stops the slow decay that otherwise turns a well-secured system into a collection of undocumented one-off tweaks.
It helps to keep the baseline distinct from other things it is sometimes confused with. It is not the same as an operational baseline of process data, which describes normal readings and trends of the physical process. Nor is it the same as the hardening procedure, which is the how-to for applying the settings. The security configuration baseline is specifically the documented known-good secure state of a device's configuration - the yardstick, not the process values it monitors and not the steps to reach it.
In oil and gas, the same device types are deployed again and again across many sites - the same RTU model at dozens of wellsites, the same HMI in every control room. That repetition is exactly where a configuration baseline pays off, because one approved specification can define the correct secure state for every instance of a device type. Instead of trusting that each site was set up correctly, an operator can measure every matching device against a single standard and see which ones conform.
This scales the effort of security across a dispersed estate. Defining a strong baseline once and applying it everywhere is far more reliable than configuring each device from scratch, and it makes onboarding a new site straightforward: build it to the baseline and it starts life in a known-good state. It also makes an audit answerable - the operator can point to the baseline as the standard and show how each device compares, rather than describing a patchwork of individual configurations.
Continuous monitoring complements this well. A cloud SCADA platform such as Merobix already gathers information from the field continuously, and the same visibility that surfaces a process anomaly can help surface configuration change - a device that stops reporting as expected, or one whose behavior shifts after a change. While the baseline itself lives in the operator's configuration management, the monitoring layer helps confirm that field devices remain in the state the baseline expects, so drift on a remote, rarely visited device does not go unnoticed until the next site trip.
A security configuration baseline is the documented target - the known-good set of secure settings a device should have. Hardening is the act of changing a device's settings to reach that target. The baseline defines what right looks like; hardening is the work of making a device match it, and comparing a device back to the baseline is how you confirm the hardening held.
Configuration drift is the gradual divergence of a device's live settings from its approved baseline over time, usually through small, unreviewed changes made during troubleshooting or maintenance that were never undone or documented. It is how a system that was once secured slowly becomes insecure. Regularly comparing devices to their baseline is how drift is detected so it can be reverted or, if legitimate, incorporated into an updated baseline.
Not directly. Industry benchmarks are a valuable starting point, but a control device often cannot adopt every generic hardening recommendation because some settings would break the functions it needs to run the process. In OT, a baseline is tailored - as hardened as the device can be while still operating correctly - and documented so the whole team agrees on what that secure, functional state is.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.