Configuration management

What Configuration Management Covers

Configuration management is the discipline of defining approved settings, software states and infrastructure baselines, then keeping them under control as systems change. It gives teams a known reference point so they can tell the difference between intended change, accidental drift and unauthorised modification.

That control spans operating system settings, application parameters, cloud and infrastructure configuration, package versions, and the relationships between them. In practice, it is less about one tool than about maintaining a reliable source of truth for what should be running.

Why Configuration Drift Creates Security Exposure

When configuration state diverges from policy, organisations can unintentionally reopen services, weaken hardening settings or reintroduce legacy versions that were already meant to be retired. Drift is especially dangerous because it often accumulates quietly, after maintenance, emergency fixes or repeated manual changes.

Small deviations can have outsized consequences: a port left open, a logging setting disabled, or a default permission restored. The security issue is not only that something changed, but that the change is no longer visible, reviewed or tied to an approved baseline.

How Configuration Management Supports Secure Operations

Effective configuration management turns security expectations into repeatable state. It lets teams compare live systems against the approved baseline, detect unauthorised changes and restore consistent settings before the gap becomes an incident.

It also improves operational reliability. Environments that are built and updated from controlled templates are easier to test, patch and recover, because the same approved configuration can be reproduced across systems rather than reinvented each time.

For organisations managing endpoints, hardening and telemetry often sit inside the configuration process. An Endpoint Hardening Checklist is one practical example of how secure baselines can be expressed as concrete settings, while the Endpoint Security Guide shows how configuration choices connect to EDR, application control and host protection.

Configuration Management in Governance and Control Frameworks

Configuration management matters because it is a control mechanism, not just an administrative process. It helps enforce baseline expectations, supports auditability and gives security teams evidence that production systems match policy.

That is why it appears in control catalogues and secure build guidance. The NIST SP 800-53 Guide is useful for understanding how configuration management fits into formal security control selection, while the NIST control catalogue itself explicitly treats configuration management as a defined security discipline. Secure-by-default thinking from CISA Secure by Design reinforces the same principle: systems should start and remain in a secure state, not rely on manual correction after deployment.

Risk and Threat Considerations

Configuration weakness is attractive to attackers because it is common, scalable and often difficult to notice. A single forgotten setting can expose many systems at once, and repeated drift can create a stable foothold for persistence, privilege abuse or lateral movement.

Failure mechanism: Inconsistent baselines, manual exceptions and poor change tracking allow insecure services, permissive settings or vulnerable versions to remain in production unnoticed.

Impact: Organisations can lose confidentiality, integrity and detection capability at the same time, especially when the misconfiguration affects authentication, exposure, logging or remote access paths.

Practitioner Guidance

Why practitioners should care: Treat configuration management as an active security control, not a documentation exercise. The practical question is whether every change can be traced, evaluated against policy and reversed if it creates risk.

What to watch for: Pay close attention to ad hoc fixes, environment-specific exceptions and settings that are changed outside the normal deployment path. Those are the most common sources of configuration drift and the hardest to recover from later.

Practitioner takeaway: The strongest programmes make baseline comparison continuous, so deviation is detected before it becomes normalised.

Related resources from NHI Mgmt Group

• Non-Human Identity Access Management
• Which configuration choices matter most for secure remote management with WinRM?
• What breaks when security configuration management is weak?
• Should organisations separate file integrity monitoring from configuration management?