Hardening a device is one thing; being able to say precisely what hardened means for that class of device is another. A security baseline is the written, approved definition of the secure state a device is supposed to be in - the specific services that should be off, the ports that should be closed, the accounts that should exist. This guide defines the baseline as an artifact in its own right, explains how one is derived from vendor and industry guidance, and shows how it becomes the yardstick every device is measured against.
Security Baseline in one line: A security baseline is the approved, documented secure configuration standard that a class of device is expected to match - specifying which services are disabled, which ports are closed, how accounts and authentication are set, and which settings are hardened. It is derived from vendor hardening guidance and recognized benchmarks and serves as the reference against which real devices are checked. In short, it is the definition of secure that turns hardening from an ad-hoc activity into something measurable.
A security baseline is best understood as a specification, not an action. Where hardening describes the work of locking a device down, the baseline is the document that says exactly what locked down means for that kind of device: this list of services must be disabled, these network ports must be closed, these default accounts must be removed or renamed, authentication must be configured this way, logging must be enabled to this destination. Some teams call the resulting reference a golden configuration - the known-good template that a freshly commissioned device should conform to before it is put into service.
The value of writing it down is that secure becomes a testable claim rather than a matter of opinion. Without a baseline, two engineers hardening the same model of controller may make different choices, and no one can say afterward whether a given device is configured correctly. With a baseline, there is a single approved standard for the class, so any device can be compared against it and judged conformant or not. That artifact is the foundation everything else builds on: you cannot meaningfully verify a configuration, detect that it has changed, or prove compliance to an auditor until you have first agreed, in writing, on what the configuration is supposed to be.
A good baseline is not invented from scratch; it is assembled from authoritative sources and then tailored to the environment. The device vendor's own hardening guide is the starting point, because the vendor knows which services their product exposes, which are safe to disable, and how to configure authentication and logging correctly. Layered on top are recognized security benchmarks and industrial security frameworks, which contribute general secure-configuration practices - closing unused ports, removing default credentials, enforcing strong authentication - that apply across many kinds of equipment. The published CIS Benchmarks and the control requirements in the IEC 62443 series are commonly used reference points for this kind of guidance.
The essential final step is adapting that general guidance to the operational reality of the plant. A setting that a generic benchmark would tighten may be needed for a control function to work, so the baseline must reconcile security recommendations with what the process genuinely requires, documenting any deliberate exceptions and the reasoning behind them. The output is a baseline that is specific to a class of device in a particular environment: strong enough to reflect real hardening guidance, yet realistic enough that devices can actually meet it without breaking the process. Because vendor advisories and benchmarks evolve, the baseline is a living document that is reviewed and updated over time rather than frozen at commissioning.
A baseline only delivers value when devices are actually measured against it. Assessment means taking a device's live configuration and comparing it, setting by setting, to the approved standard: is the service that should be disabled actually off, is the port that should be closed actually closed, do the accounts match what the baseline permits. Each mismatch is a deviation - a concrete, named gap that can be prioritized and remediated - rather than a vague worry that the device might not be secure. This same comparison underpins compliance reporting, because demonstrating that devices conform to an approved baseline is often exactly what an auditor or a regulator wants to see.
Across a distributed estate of remote sites, keeping many devices measured against their baselines is a logistics problem as much as a technical one, and this is where centralized visibility helps. A cloud monitoring platform such as Merobix gives operators a single vantage point over geographically scattered assets, making it practical to know the state and behavior of devices that no one visits often. The baseline defines the target; comparing the fleet against it, and being alerted when a device stops matching, is how that target is enforced in practice. The baseline is the standard, and continuous checking against it - the subject of configuration drift detection - is what keeps the standard from quietly eroding over time.
Hardening is the activity of locking a device down - disabling services, closing ports, tightening accounts. A security baseline is the written specification that defines exactly what hardened should mean for that class of device, so the work can be measured against a standard. Hardening is the action; the baseline is the approved definition of the secure state that action is supposed to produce.
A baseline is assembled from the device vendor's hardening guidance, recognized security benchmarks such as the CIS Benchmarks, and industrial frameworks like IEC 62443, then tailored to the specific operational environment. The tailoring step reconciles general secure-configuration advice with what the process actually needs, documenting any deliberate exceptions. Because vendor advisories and benchmarks change over time, the baseline is reviewed and updated rather than fixed permanently.
The device's live configuration is compared setting by setting to the approved baseline: confirming that services meant to be disabled are off, ports meant to be closed are closed, and accounts match what is permitted. Each difference is recorded as a deviation that can be prioritized and fixed, and the same comparison supports compliance reporting. Continuous checking of this kind - configuration drift detection - is what keeps a device conformant after commissioning.
This page references the standards, specifications, and official documentation published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.