Every security incident investigation eventually arrives at the same question: how was this system configured, and was that configuration correct? Configuration management is the discipline that ensures organizations can answer that question with confidence — not by guessing or checking manually, but through systematic, automated, and auditable processes that keep every system in a known, secure state.
In environments with hundreds or thousands of servers, network devices, and cloud resources, manual configuration is not just impractical — it is a security liability. A single misconfigured firewall rule, an overlooked default password, or an unpatched service left running can provide the foothold an attacker needs. Configuration management eliminates this class of risk by treating system configuration as code: versionable, testable, repeatable, and enforceable.
This guide covers configuration management from the ground up — its core concepts, the tools that implement it, its relationship to security hardening and compliance, and the practices that distinguish mature organizations from those operating on hope and manual checklists.
What Is Configuration Management?
Configuration management (CM) is a systems engineering discipline that establishes and maintains the consistency of a system’s functional and physical attributes throughout its lifecycle. In IT, this translates to defining, deploying, monitoring, and enforcing the desired state of every component in the technology stack — from operating system parameters and installed packages to application settings, network configurations, and access controls.
The concept originates from manufacturing and defense engineering, where it was formalized in the 1950s to ensure that complex weapons systems were built, maintained, and modified in a controlled manner. The U.S. Department of Defense standard MIL-STD-973 and later ANSI/EIA-649 codified the practice. IT adopted the principles in the 1990s, initially through ITIL (Information Technology Infrastructure Library) and later through the DevOps movement, which transformed configuration management from a documentation exercise into an automated, code-driven practice.
A modern configuration management system provides four core capabilities:
- Identification — cataloging every configuration item (CI) and its attributes
- Control — ensuring changes follow a defined process and are authorized
- Status accounting — recording and reporting the current state of all CIs
- Verification and audit — confirming that actual configurations match intended configurations
Without these capabilities, an organization cannot reliably answer basic questions: What software version is running on server X? Who changed the firewall rule on device Y, and when? Are all production databases configured identically? These questions are not academic — they are the ones incident responders, auditors, and compliance officers ask daily.
The Configuration Management Database (CMDB)
At the center of traditional configuration management sits the CMDB — a repository that stores information about all significant components of the IT environment and their relationships. The concept was popularized by ITIL and remains a cornerstone of IT service management.
A CMDB contains configuration items (CIs), which can be hardware (servers, switches, firewalls), software (operating systems, applications, middleware), documentation (runbooks, network diagrams), or services (email, DNS, authentication). Each CI has attributes — serial numbers, IP addresses, software versions, owners, support contracts — and relationships to other CIs (e.g., “application X runs on server Y, which is connected to switch Z”).
What Makes a CMDB Valuable
The value of a CMDB is not in the data it stores, but in the questions it allows you to answer:
- Impact analysis — if switch A fails, which services are affected?
- Root cause investigation — what changed in the environment before the incident?
- Compliance reporting — which systems are running unauthorized software?
- Capacity planning — how many servers are nearing end of life?
Common CMDB Pitfalls
Many CMDB implementations fail because they rely on manual data entry. Information becomes stale within weeks, and teams stop trusting it. Successful CMDBs are populated automatically through discovery tools (network scanners, agent-based inventory, cloud API integrations) and validated continuously against actual system states.
The most widely deployed CMDB platforms include ServiceNow CMDB, BMC Atrium, Device42, and open source alternatives like i-doit and iTop. Cloud providers offer their own inventory services — AWS Config, Azure Resource Graph, and Google Cloud Asset Inventory — which function as cloud-native CMDBs for their respective platforms.
Infrastructure as Code (IaC)
Infrastructure as Code represents the most significant evolution in configuration management over the past decade. IaC applies software engineering practices — version control, code review, testing, and continuous integration — to infrastructure and system configuration.
Instead of logging into a server and manually editing configuration files, an engineer writes a declarative definition of the desired state. A tool then reads that definition and makes the system conform to it. If someone manually changes a setting, the tool detects the deviation and reverts it. If a new server needs to be deployed, it receives the exact same configuration as every other server in its role.
Declarative vs Imperative Approaches
IaC tools fall into two paradigms:
Declarative tools describe the desired end state without specifying the steps to achieve it. The tool figures out what changes are necessary. Terraform, Puppet, and SaltStack (in state mode) follow this approach. The advantage is idempotency — applying the same definition multiple times produces the same result, regardless of the starting state.
Imperative tools define a sequence of commands to execute. Ansible playbooks are technically imperative (they describe ordered tasks), though many Ansible modules behave declaratively by checking current state before making changes. Shell scripts are purely imperative and lack built-in idempotency, which is why they are unreliable for configuration management at scale.
Version Control as the Source of Truth
When infrastructure definitions live in Git, every change is tracked with a timestamp, author, and commit message. Code review processes ensure that a second pair of eyes evaluates every modification before it reaches production. Branches and pull requests enable testing changes in isolation. If a change causes problems, a git revert restores the previous known-good state in seconds.
This approach — often called GitOps when combined with automated deployment pipelines — transforms infrastructure from something that “just happened over time” into a fully auditable, reproducible artifact.
Configuration Management Tools
The ecosystem of configuration management tools has matured considerably. Each tool occupies a slightly different niche, and many organizations use several in combination.
Ansible
Ansible, maintained by Red Hat, is the most widely adopted configuration management tool in 2026. Its popularity stems from its low barrier to entry: it is agentless (communicating over SSH or WinRM), uses YAML for playbook definitions, and requires no special infrastructure beyond a control node with Python installed.
Ansible operates by connecting to target systems and executing modules — small programs that check the current state of a resource and make changes if necessary. Playbooks define ordered lists of tasks, and roles provide reusable, shareable units of configuration. Ansible Galaxy offers thousands of community-contributed roles for common scenarios.
Key strengths: simplicity, agentless architecture, massive community, excellent for ad-hoc operations and orchestration. Key limitations: performance at very large scale (thousands of nodes) requires tuning (parallelism settings, Mitogen plugin), and its imperative task model can be less predictable than purely declarative tools.
Puppet
Puppet uses a declarative, model-driven approach with its own domain-specific language (Puppet DSL). An agent running on each managed node periodically checks in with a central Puppet server, receives a compiled catalog of desired states, and enforces them. This pull-based model ensures continuous compliance — if someone manually changes a file that Puppet manages, the agent reverts it on the next run (typically every 30 minutes).
Key strengths: mature compliance enforcement, strong reporting (Puppet Enterprise dashboard), excellent for large, heterogeneous environments that need continuous state enforcement. Key limitations: steeper learning curve (custom DSL), requires agent installation on all managed nodes, and the Puppet server infrastructure adds operational overhead.
Chef
Chef follows an imperative, code-driven philosophy using Ruby-based “recipes” and “cookbooks.” Like Puppet, it uses a client-server model with agents (chef-client) pulling configurations from a Chef server. Chef’s Ruby foundation provides maximum flexibility — anything you can express in code, you can express in Chef.
Key strengths: extreme flexibility, mature ecosystem (Chef Supermarket), strong testing framework (InSpec, Test Kitchen). Key limitations: Ruby knowledge required, higher complexity than Ansible, declining market share relative to Ansible and Terraform.
Terraform
Terraform, by HashiCorp, occupies a distinct position in the ecosystem. While Ansible, Puppet, and Chef focus on configuring systems that already exist, Terraform focuses on provisioning infrastructure — creating and managing cloud resources (VMs, networks, load balancers, DNS records, databases) through provider APIs.
Terraform uses HashiCorp Configuration Language (HCL) to define resources declaratively. Its state file tracks what infrastructure currently exists, enabling it to calculate the minimal set of changes needed to reach the desired state. The terraform plan command shows exactly what will change before any modification is applied — a critical safety mechanism for production infrastructure.
Key strengths: cloud-agnostic provisioning, excellent state management, plan-before-apply workflow, massive provider ecosystem. Key limitations: not designed for ongoing configuration management of running systems (use Ansible or Puppet for that), state file management requires careful handling (remote backends, locking).
SaltStack
SaltStack (Salt) combines a high-speed communication bus (ZeroMQ) with both imperative (remote execution) and declarative (state system) configuration management. Its speed advantage — Salt can reach thousands of nodes in seconds — makes it particularly suitable for large-scale environments requiring rapid configuration changes.
Key strengths: exceptional speed and scalability, event-driven automation (reactor system), dual imperative/declarative modes. Key limitations: steeper learning curve, smaller community than Ansible, documentation quality historically inconsistent.
Choosing the Right Combination
In practice, many organizations adopt a layered approach: Terraform for provisioning infrastructure, Ansible for configuring systems after provisioning, and a CMDB for tracking what exists and how it relates. The key principle is that no system should be configured manually — every setting should originate from code, and every deviation should be detected and corrected.
Configuration Drift
Configuration drift is the gradual divergence of a system’s actual state from its intended state. It is one of the most insidious problems in IT operations and one of the primary motivations for adopting configuration management tooling.
How Drift Occurs
Drift typically enters through several vectors:
- Manual hotfixes — an engineer SSHs into a production server at 2 AM to fix an urgent issue, changes a configuration file, and forgets to update the IaC definition
- Failed or partial updates — a deployment script completes on 98 of 100 servers, leaving two in an inconsistent state
- Software updates — package managers may modify default configuration files during upgrades
- Environmental differences — development, staging, and production environments accumulate subtle differences over time
- Shadow IT — teams install unauthorized software or modify settings outside the change management process
Why Drift Is Dangerous
From a security perspective, drift is particularly hazardous because it creates uncertainty. If you cannot guarantee that all systems are in a known state, you cannot guarantee that they are in a secure state. Specific risks include:
- Undetected vulnerabilities — a server where a security module was accidentally disabled during troubleshooting and never re-enabled
- Compliance violations — systems that once met CIS Benchmark requirements but no longer do after accumulated manual changes
- Incident response complications — when investigating a breach, you need to know the exact configuration of affected systems, and drift makes this unreliable
- Unreproducible environments — the classic “it works on my machine” problem extended to production infrastructure
Detecting and Preventing Drift
Configuration management tools provide drift detection as a core feature. Puppet’s agent reports on every enforcement run, highlighting resources that required correction. Ansible’s --check mode (dry run) compares desired state against actual state without making changes. Terraform’s terraform plan reveals infrastructure drift. Dedicated tools like AWS Config Rules, Chef InSpec, and Open Policy Agent (OPA) enable continuous compliance monitoring with alerting when drift is detected.
The most effective drift prevention strategy combines automated enforcement (tools that continuously correct deviations), immutable infrastructure (replacing drifted servers rather than fixing them), and cultural practices (treating manual production changes as incidents that require root cause analysis).
Configuration Hardening
Configuration hardening is the process of reducing a system’s attack surface by disabling unnecessary features, removing default credentials, restricting permissions, and applying security-focused settings. It is, in essence, the security-specific application of configuration management.
The Default Configuration Problem
Out-of-the-box configurations for operating systems, databases, web servers, and applications are designed for ease of setup, not security. A fresh Linux installation may have unnecessary services running, default firewall rules that allow all traffic, and sample accounts with known credentials. A default database installation might listen on all network interfaces, permit remote root login, and include example databases with weak permissions.
Hardening transforms these defaults into a production-ready, security-conscious configuration. The challenge is doing this consistently across hundreds of systems — which is precisely where configuration management tools excel.
CIS Benchmarks
The Center for Internet Security (CIS) publishes detailed hardening guides — called CIS Benchmarks — for over 100 technologies, including operating systems (Windows Server, Ubuntu, RHEL, macOS), databases (MySQL, PostgreSQL, Oracle), cloud platforms (AWS, Azure, GCP), and applications (Apache, Nginx, Docker, Kubernetes).
Each benchmark contains hundreds of specific recommendations, organized into scored and unscored categories. Scored recommendations are those the CIS considers essential for security. For example, the CIS Benchmark for Ubuntu Linux 22.04 includes recommendations like:
- Ensure permissions on /etc/passwd are configured (mode 644)
- Ensure SSH root login is disabled
- Ensure firewall is active with a default deny policy
- Ensure audit log storage size is configured
- Ensure password expiration is 365 days or less
Configuration management tools can automate CIS Benchmark compliance. Ansible roles like ansible-lockdown implement CIS Benchmarks as playbooks. Chef InSpec profiles translate benchmarks into testable code. Puppet modules enforce benchmark settings continuously. This automation transforms hardening from a one-time project into a continuously enforced state.
DISA STIGs
For organizations operating in government or defense contexts, the Defense Information Systems Agency (DISA) publishes Security Technical Implementation Guides (STIGs) — configuration standards even more prescriptive than CIS Benchmarks. STIGs classify findings by severity (Category I, II, III) and are often mandatory for systems processing government data.
Compliance and Regulatory Frameworks
Configuration management intersects with virtually every compliance and regulatory framework. Maintaining systems in a documented, controlled, and auditable state is a universal requirement.
DORA (Digital Operational Resilience Act)
DORA, which applies to financial entities operating in the European Union, places explicit requirements on ICT asset management and configuration control. Article 8 requires financial entities to identify, classify, and adequately document all ICT assets. Article 9 mandates protection and prevention measures including configuration management. Article 11 requires business continuity plans that account for system configurations. Configuration management provides the tooling and processes to demonstrate DORA compliance through automated inventory, change tracking, and state verification.
ISO 27001
ISO 27001 Annex A includes several controls directly related to configuration management: A.8.9 (Configuration management) requires organizations to establish, document, implement, monitor, and review configurations, including security configurations, for hardware, software, services, and networks. Configuration management tools provide the evidence trail that auditors require.
PCI DSS
The Payment Card Industry Data Security Standard requires hardened system configurations (Requirement 2), maintained firewalls (Requirement 1), and documented change management processes (Requirement 6.4). Configuration management tools enforce these requirements continuously rather than relying on periodic manual audits.
NIS2 Directive
The EU’s Network and Information Security Directive (NIS2) requires essential and important entities to implement risk management measures that include configuration management, vulnerability handling, and secure system administration practices. Automated configuration management provides demonstrable evidence of these controls.
ITIL Configuration Management
ITIL (Information Technology Infrastructure Library) formalizes configuration management as a practice within IT service management. ITIL 4 defines it as the practice of ensuring that accurate and reliable information about the configuration of services and the CIs that support them is available when and where it is needed.
Key ITIL CM Concepts
- Configuration Item (CI) — any component that needs to be managed to deliver a service. This includes hardware, software, documentation, and personnel.
- Configuration Model — a representation of the relationships and dependencies between CIs. Understanding these relationships is critical for impact analysis during changes and incidents.
- Configuration Baseline — a documented, approved snapshot of a CI’s configuration at a specific point in time. Baselines provide rollback targets and audit reference points.
From ITIL to Automation
Traditional ITIL configuration management was heavily process-oriented — manual documentation, periodic audits, and paper-based change records. Modern implementations retain ITIL’s conceptual framework but automate the execution. IaC repositories serve as living documentation. CI/CD pipelines enforce change processes. Monitoring tools verify configuration baselines continuously. The ITIL principles remain valid; the implementation has simply evolved from manual processes to automated systems.
Security Implications of Configuration Management
Configuration management is not merely an operational convenience — it is a fundamental security control. Its absence directly increases organizational risk across multiple dimensions.
Attack Surface Reduction
Every unnecessary service, open port, default account, and excessive permission represents a potential attack vector. Configuration management enables systematic identification and elimination of these exposures. When the desired state explicitly defines which services should run, which ports should be open, and which accounts should exist, anything outside that definition is unauthorized and can be detected and remediated automatically.
Consistent Security Posture
In environments without configuration management, security depends on the diligence of individual administrators. One engineer might disable root SSH access; another might leave it enabled because a script requires it. Configuration management eliminates this variability by enforcing a single, organization-wide security standard across all systems in a given role.
Audit Trail and Forensics
When every configuration change passes through version control, the organization maintains a complete, tamper-evident history of who changed what, when, and why. During incident investigations, this audit trail is invaluable — it enables responders to determine whether a configuration change preceded the incident, whether attacker-modified settings persist, and what the known-good state should be for remediation.
Rapid Recovery
When systems are defined in code, rebuilding them after a compromise is straightforward. Rather than attempting to clean a compromised server — a process that can never guarantee complete remediation — the organization destroys the affected instance and provisions a new one from the known-good IaC definition. This approach, sometimes called “burn and rebuild,” is only possible when configuration management captures the complete system state.
Best Practices for Configuration Management
Implementing configuration management effectively requires more than selecting a tool and writing definitions. The following practices distinguish mature implementations from those that create as many problems as they solve.
1. Start With an Inventory
You cannot manage what you do not know exists. Before writing a single line of IaC, conduct a thorough discovery of the existing environment. Automated discovery tools, network scanners, and cloud provider APIs identify systems that documentation has forgotten. This inventory becomes the foundation of your CMDB and the scope for your configuration management rollout.
2. Define Baselines Incrementally
Attempting to define the complete desired state of every system simultaneously is a recipe for project failure. Start with the highest-risk, highest-impact configurations — authentication settings, firewall rules, encryption parameters — and expand coverage incrementally. Each iteration adds new managed resources and reduces the unmanaged attack surface.
3. Treat Configuration as Code — Completely
Store all definitions in version control. Require code reviews for changes. Run automated tests (linting, syntax checks, integration tests) in CI pipelines. Tag releases. Maintain separate branches for development, staging, and production. Apply the same rigor to infrastructure code that you apply to application code, because a bug in a Terraform module can be just as destructive as a bug in application logic.
4. Enforce Immutability Where Possible
Immutable infrastructure — the practice of never modifying a running system, but instead replacing it with a new instance built from the current definition — eliminates drift by design. Container orchestration (Kubernetes), machine image pipelines (Packer), and serverless architectures naturally support this pattern. Where full immutability is impractical, enforce it for the most security-sensitive components.
5. Monitor and Alert on Drift
Detecting drift is only useful if someone acts on the detection. Configure alerting so that drift events generate notifications routed to the appropriate team. Categorize drift by severity — an unauthorized change to a firewall rule demands immediate attention, while a modified MOTD banner can wait for the next maintenance window.
6. Integrate With Change Management
Configuration management tools should not operate in isolation from organizational change processes. Changes to IaC definitions should follow the same approval workflows as other changes to production systems. Emergency changes (hotfixes applied outside the normal process) should trigger a mandatory follow-up task to update the IaC definition and prevent recurrence of drift.
7. Test Configurations Before Deployment
Use staging environments that mirror production to validate configuration changes before applying them. Tools like Ansible Molecule, Test Kitchen (Chef), and Terraform’s plan command enable pre-deployment verification. For compliance-focused configurations, run InSpec or OpenSCAP scans against staging systems to confirm benchmark adherence before production rollout.
8. Document Exceptions
Not every system can conform to every standard. Legacy applications may require deprecated TLS versions. Third-party appliances may not support agent-based management. Document these exceptions explicitly, including the risk they represent, the compensating controls in place, and the planned remediation timeline. An acknowledged, documented exception is manageable; an unknown deviation is a vulnerability.
Summary
Configuration management is the foundational discipline that transforms IT infrastructure from a collection of individually maintained systems into a coherent, auditable, and secure environment. By defining desired states in code, enforcing them with automation, detecting deviations through continuous monitoring, and maintaining a comprehensive inventory in a CMDB, organizations gain control over the complexity that would otherwise undermine their security posture.
The tools have matured — Ansible, Terraform, Puppet, Chef, and SaltStack each address specific needs within the configuration management lifecycle. The frameworks are clear — CIS Benchmarks, DORA, ISO 27001, and ITIL provide the standards and processes that guide implementation. What remains is execution: adopting these practices, embedding them into daily operations, and treating configuration not as a one-time setup task but as a continuously managed, continuously verified attribute of every system in the environment.
In a threat landscape where attackers routinely exploit misconfigurations — open S3 buckets, default credentials, disabled security controls — configuration management is not optional. It is the difference between an environment where security is designed, enforced, and verified, and one where it is merely hoped for.
Related terms
Our services
Related services and products
Frequently asked questions
What is the difference between configuration management and change management?
Configuration management tracks and maintains the desired state of systems — what software is installed, how services are configured, what parameters are set. Change management is a process governing how modifications are proposed, approved, and implemented. They complement each other: change management decides what should change, configuration management enforces and verifies that the change was applied correctly.
Do I need a CMDB if I already use Infrastructure as Code?
Yes, they serve different purposes. IaC defines and enforces the desired state of infrastructure, while a CMDB provides a centralized inventory of all configuration items and their relationships. IaC tells you how things should be configured; a CMDB tells you what exists, who owns it, and how components depend on each other. In mature organizations, IaC repositories feed data into the CMDB automatically.
Which configuration management tool should I choose — Ansible, Puppet, or Terraform?
It depends on your use case. Ansible is the easiest to adopt (agentless, YAML-based) and excels at configuration enforcement and ad-hoc tasks. Puppet is strongest for continuous compliance at scale with its declarative model. Terraform is specifically designed for infrastructure provisioning (creating VMs, networks, cloud resources), not ongoing configuration. Many organizations use Terraform for provisioning and Ansible for configuration — they complement rather than compete.
What is configuration drift and why is it dangerous?
Configuration drift occurs when a system's actual state diverges from its intended or documented state — typically through manual changes, failed updates, or undocumented hotfixes. It is dangerous because it creates security blind spots (an opened firewall port that was never closed), compliance violations (settings that no longer match CIS benchmarks), and operational unpredictability (systems that behave differently despite supposedly identical configurations).
How does configuration management relate to CIS Benchmarks and DORA?
CIS Benchmarks provide specific, prescriptive configuration standards for hardening operating systems, databases, and applications. Configuration management tools automate the enforcement and verification of these benchmarks. DORA (Digital Operational Resilience Act) requires financial entities to maintain documented, tested, and auditable ICT configurations. Configuration management provides the tooling and processes to meet DORA's requirements for asset inventory, change control, and resilience testing.
