Secure baselines — SY0-701
CompTIA Security+ SY0-701 concept page for Secure Baselines (D4/4.1): what it is, the mental model, when vs. hardening, common misconception, and exam signals.
WHAT IT IS
A secure baseline is a documented set of specifications for an information system or configuration item that has been formally reviewed and agreed upon at a specific point in time, and that can be changed only through established change control procedures.
The NIST glossary defines a baseline configuration (synonym: configuration baseline) as: "A documented set of specifications for an information system or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures." (Source: NIST SP 800-128, via CSRC glossary.)
A secure baseline applies this idea specifically to the security properties of a system — the approved-minimum state from which all instances of that system are built and to which they must continuously conform.
Mental model
Think of a secure baseline as a stamp on a blueprint. Before any unit leaves the factory floor, it must match that blueprint exactly. After delivery, any deviation from the blueprint — intentional or accidental — must go through a formal approval gate before it is accepted.
This "approved snapshot + change gate" frame explains three things at once:
- Why a baseline must be documented (the blueprint must exist to be compared against).
- Why it must survive change control (the gate is what keeps the blueprint meaningful).
- Why monitoring for deviation matters — anything that slips past the gate is an unauthorized change, which is itself a security event.
When to use it
Candidates frequently conflate secure baseline with hardening. They are related but distinct activities. NIST SP 800-152 defines hardening as "a process intended to eliminate a means of attack by patching vulnerabilities and turning off nonessential services." A baseline is what you document after hardening has been applied and reviewed.
| Secure Baseline | Hardening | |
|---|---|---|
| What it is | A formally reviewed, approved snapshot of system specifications | A process of patching vulnerabilities and disabling nonessential services |
| When it happens | After hardening and formal review | Before (or as part of) establishing a baseline |
| Primary output | Documented configuration specification | Reduced attack surface on a live system |
| Governing mechanism | Change control procedures | Technical actions (patching, disabling services) |
| Ongoing role | Reference state that triggers alerts when violated | One-time or periodic activity repeated to maintain the baseline |
Use "hardening" when the question asks how attack surface is reduced. Use "secure baseline" when the question asks what approved state systems must conform to, or what the organization compares against when detecting unauthorized change.
COMMON MISCONCEPTION
The trap: Treating a secure baseline as identical to the hardened state of a single running system, rather than as the formally documented and approved specification that governs all instances of that system class.
This matters because:
- A system can be hardened without ever having a baseline documented. Without the documentation and change control gate, there is no mechanism to detect drift.
- A baseline is not just a snapshot of one machine — it is an agreed-upon specification against which every instance of that system type is measured.
- Configuration management, defined by NIST as "a collection of activities focused on establishing and maintaining the integrity of information technology products and systems, through control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the system development life cycle" (NIST SP 800-128), is the broader discipline that uses baselines — the baseline itself is only one artifact within that discipline.
The exam can exploit this by presenting a scenario where a system has been hardened and asking what step was skipped before deployment. The answer turns on whether the hardened configuration was formally documented and subjected to change control — that is, whether a baseline was established.
How it shows up on the exam
The cognitive target is application: candidates must recognize which scenario action (documenting an approved configuration, enforcing change control, detecting drift, deploying from a known-good image) corresponds to secure baseline practice — and which corresponds to the adjacent concept of hardening.
Signal phrases that point toward secure baseline reasoning:
- "approved configuration" / "formally reviewed specifications"
- "change control" or "change management" in a configuration context
- "deviation from standard" / "unauthorized change" / "configuration drift"
- "deploy from a known-good state" / "re-image to restore compliance"
- "minimum security requirements" that a system class must meet before going live
A common misconception candidates carry into exam questions is that any locked-down system has a baseline. The NIST definition requires formal review and agreement — the approval step, not just the technical hardening, is what constitutes the baseline. Questions testing this distinction will describe a technically hardened environment and ask about a process gap, pointing toward the documentation or change control element.
Related concepts
- Hardening targets — the specific system types (OS, firmware, applications, cloud) to which baseline configurations are applied
- Wireless security — wireless infrastructure requires its own baseline configurations, particularly around authentication protocols and default credential changes
- Mobile device management — MDM enforces baseline configurations at scale across mobile endpoints, detecting and remediating drift automatically
Sources
Every claim on this page traces to the public exam blueprint and official documentation: