A secure baseline is useful only when teams know what it covers, how it was approved, how it is deployed, which deviations are allowed, how drift is detected, and who is accountable for restoring compliance. Configuration management should make the secure state repeatable and observable rather than depend on a checklist completed at build time.
NIST SP 800-128 describes security-focused configuration management as an integral part of configuration management, while CISA guidance repeatedly identifies insecure defaults, inconsistent configuration, exposed management services, and excessive privilege as recurring weaknesses. This guide translates that guidance into an operating model.
Start by grouping assets into configuration domains that can share a meaningful baseline: Windows workstations, Windows servers, Linux servers, network devices, cloud accounts, SaaS tenants, container hosts, databases, virtualization platforms, endpoint-security tooling, and administrative workstations. Avoid one giant baseline that mixes controls no single system can actually implement.
Assign an owner for each baseline and identify the technical authorities who can approve changes. Record the source material behind the baseline, the supported operating-system or product versions, required management tooling, exceptions, and test evidence. A baseline without an owner becomes stale quickly; a baseline without version boundaries can create unsafe assumptions during upgrades.
Prioritize high-consequence assets and common attack paths first. Internet-facing systems, privileged management platforms, identity infrastructure, remote access, security tooling, backup administration, and network management deserve earlier attention because configuration mistakes there can create broad compromise paths.
Replace vague requirements such as “harden the server” with testable configuration statements: disable unused services, require approved cryptographic protocols, restrict remote administration, enable required logging, limit local administrator membership, enforce screen-lock behavior, disable legacy authentication, and configure endpoint protection. Each requirement should identify the expected value and the system population it applies to.
Some controls apply everywhere; others depend on application function or deployment model. Mark settings as mandatory, recommended, or conditional and document the condition. This prevents teams from creating undocumented exceptions simply because a generic requirement conflicts with a legitimate service need.
CISA has repeatedly emphasized secure-by-default design and the risks of non-secure default configuration. When a platform can ship or deploy with a safer default that does not break the service, prefer that state over relying on every administrator to remember a post-install hardening step.
Harden administrative interfaces, remote-management protocols, jump hosts, device consoles, cloud management endpoints, and automation credentials. A well-hardened workload can still be compromised through an exposed or weakly authenticated management plane.
Use the platform’s native policy and configuration tooling where practical: device-management policy, configuration-management systems, infrastructure as code, image pipelines, cloud policy, container admission controls, network configuration templates, or vendor management APIs. Manual hardening should be the exception because it is difficult to prove, repeat, and maintain.
Test baseline changes in representative environments before broad deployment. Security changes can affect authentication, management connectivity, application dependencies, monitoring agents, backup software, legacy protocols, and support tooling. Define rollback conditions and validate that emergency access remains available.
Version baselines like code. A change should have an identifier, rationale, approver, effective date, affected population, test result, deployment status, and rollback information. This allows incident responders and auditors to determine what configuration was intended at a particular point in time.
An exception should identify the exact setting that cannot be applied, why the service requires the deviation, affected assets, accountable owner, compensating controls, expiration or review date, and evidence required for closure. Avoid blanket exceptions for entire product families when only a subset of systems needs the deviation.
Exceptions should be reviewed after product upgrades, architecture changes, vendor fixes, or changes in exposure. A setting that was incompatible six months ago may be fully supported today. Expiration prevents temporary workarounds from silently becoming permanent security design.
Collect configuration evidence on a cadence appropriate to the asset and consequence. High-impact cloud, identity, endpoint, and management settings may need near-real-time monitoring, while slower-changing infrastructure can be assessed periodically. Track assets not reporting as a separate condition rather than counting them as compliant.
Escalate changes that weaken authentication, expose management interfaces, disable logging, widen network access, grant privilege, change security tooling, weaken encryption, disable backups, permit public sharing, or alter update policy. Not every cosmetic deviation deserves the same response.
Configuration changes that have an approved change record may be expected; changes without one may indicate emergency work, automation failure, administrator error, or compromise. Correlation reduces noise and makes unauthorized change easier to identify.
Review proposed changes for security effect before implementation. Changes to firewall rules, IAM policy, routing, endpoint controls, identity settings, administrative groups, logging, cryptography, backup configuration, remote access, and cloud exposure should trigger explicit security consideration.
Emergency changes still need traceability. Record who made the change, why, what systems were affected, what validation was performed, and when the environment returned to a controlled state. After an incident, use the configuration record to determine whether the emergency state introduced new exposure.
Do not confuse change approval with security approval. A technically successful deployment can still weaken the baseline. Compare post-change state with the approved secure configuration and update the baseline only when the organization intentionally changes its standard.
Choose two high-value technology classes, define owners, inventory assets, document current configuration sources, establish versioned baselines, and identify settings with the highest security consequence.
Automate deployment and assessment, create the exception workflow, connect configuration changes to change records, and alert on a small set of high-risk deviations.
Measure coverage and restoration time, review exceptions, test rollback, add additional technology classes, and use recurring drift findings to improve the baseline and deployment process.
Follow the next implementation topic without returning to search.
Prioritize and remediate vulnerabilities using asset, exploitation, exposure, ownership, exception, and verification evidence
Continue readingBuild repeatable security operations and evidence practices
Continue readingDiscover, own, prioritize, reduce, and verify internet-facing exposure across internal and supplier-hosted services
Continue readingUse the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.