Your systems are fully patched. Your vulnerability scanner comes back clean. But are they actually secure?
What You’ll Learn
- What configuration drift actually looks like in production
- Why patch compliance doesn’t equal security
- The difference between CVEs and configuration risk
- The most common ways hardened systems drift over time
- How misconfiguration gets exploited after initial access
- Why audits fail even when systems were hardened correctly
- How to keep systems aligned with your security baseline
For most IT and security teams, patch management is a well-understood discipline. Vendors like Microsoft release monthly security updates, vulnerability scanners identify the gaps to identify missing patches, and teams work through the remediation queue. It’s not glamorous, but the process is clear.
Configuration security is a different story. There’s no equivalent of Patch Tuesday. The attack surface is harder to see. And the tools that monitor your environment for software vulnerabilities generally don’t track configuration changes at all.
This is the world of configuration drift and it’s one of the more underappreciated risks in a typical IT environment. This post explains what configuration drift is, how it happens, why it matters from both a security and compliance perspective, and what it takes to actually stay on top of it.
Configuration drift is the gradual deviation of a system from its approved secure configuration baseline over time due to operational changes, updates, or administrative actions.
If configuration drift is a new concept for you, we walk through real examples and attack scenarios in this video-on-demand recording.
Configuration Vulnerabilities vs Software Vulnerabilities
Before diving into drift, it’s worth establishing a clear distinction between the two main categories of system vulnerability.
Software vulnerabilities (CVEs) are flaws in code. They exist in the source of an application or operating system, and they’re remediated by deploying a patch. Once patched, the vulnerability is considered closed. It won’t reappear unless the patch is removed, or the system is rebuilt from an old image, or in other extraordinary circumstance.
Configuration vulnerabilities are different. They are not flaws in code but weaknesses that arise when a system operates in an insecure state. There is no patch that fixes them. Remediation requires identifying the insecure setting, changing the configuration, or removing the exposed component entirely.
While software vulnerabilities are tracked in databases such as NIST NVD, CISA’s Known Exploited Vulnerabilities catalog, and vendor advisories, configuration weaknesses are typically documented in hardening standards like CIS Benchmarks, DISA STIGs, and vendor security guidance. Both can be exploited by attackers, but they require fundamentally different remediation approaches.
| Software Vulnerability (CVE) | Configuration Vulnerability | |
| What it is | A flaw in application or OS code | An insecure system setting or misconfiguration |
| How it’s fixed | Deploy a patch or hotfix | Change or remove the insecure setting |
| Automated remediation | Yes — patch management tools | Requires configuration management platform such as CHS |
| Monitoring | Vulnerability scanners (continuous) | Often manual and infrequent |
| Example source | NVD, CISA vendor advisories | CIS Benchmarks, DISA STIGs, vendor baselines |
| Can it revert? | No — patch stays applied | Yes — drift can re-expose the system |
This gap between patch management and configuration enforcement is why many organizations adopt dedicated hardening automation platforms such as CalCom Hardening Suite (CHS), which continuously enforces approved baselines rather than relying on periodic checks.
What Is Configuration Drift?
System hardening is the process of configuring a system in accordance with a recognized security baseline. Well-known examples include the CIS Benchmarks (published by the Center for Internet Security) and DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides). These documents define what a secure configuration looks like for a given OS, application, or platform.
Configuration drift is what happens when that secure state degrades over time. A setting that was correctly hardened at deployment is no longer correctly hardened either because something changed it, or because something changed around it.
Drift typically occurs through one of three mechanisms:
• Privileged user changes — Someone with system access modifies a setting, either deliberately or as a side effect of troubleshooting. The change may seem minor at the time, but if it touches a hardened configuration it can reintroduce a vulnerability.
• Patch conflicts — Less common, but real: a software patch can overwrite or reset configuration values as part of its deployment. A system that was hardened before the patch may no longer be hardened after it.
• OS and platform upgrades — This one catches a lot of teams off guard. When you upgrade an operating system — even a minor version bump — the new version may ship with different defaults. Previously hardened settings don’t automatically carry over. You need to re-verify and re-enforce the baseline after every significant update.
An OS upgrade that improves security features can simultaneously undo your existing hardening work. Always re-verify your baseline after any platform change.
How Attackers Exploit Configuration Drift
Configuration vulnerabilities are, from an attacker’s perspective, low-hanging fruit. The CIS Benchmarks are publicly available documents. That same reference guide your team uses to harden systems is also a detailed map of potential attack vectors if those controls aren’t in place or have drifted, it’s straightforward to identify and exploit them.
What makes this especially dangerous is the visibility problem. Most SIEM platforms, EDR tools, and vulnerability scanners don’t monitor configuration changes out of the box. If an attacker exploits a misconfigured setting, there may be no alert, no log entry, and no indication that anything happened. It’s been called a ‘silent attack path’ for exactly this reason.
Configuration weaknesses tend to be most valuable to attackers who already have a foothold. They’re less useful as an initial entry vector and more useful for privilege escalation, lateral movement, and persistence — the activities that turn a minor compromise into a major incident. A couple of concrete examples:
Linux: IPv4 Source Routing
The sysctl configuration on Linux systems controls a wide range of kernel parameters. One setting (net.ipv4.conf.all.accept_source_route) determines whether the system will accept packets with source routing enabled. When it’s left at its default (or set to 1), it can be abused for traffic interception and man-in-the-middle attacks. The hardened value is 0.
This isn’t theoretical threat groups including APT 41 and APT 34 have exploited exactly this class of misconfiguration. And it’s one of dozens of sysctl settings that should be reviewed and locked down on any Linux system.
Windows: RDP Clipboard Redirection
RDP clipboard redirection is an example of a setting that doesn’t create an entry point but dramatically amplifies what an attacker can do once they’re in. With clipboard redirection enabled, an attacker who has gained control of one system can use the clipboard channel to move malicious code to other endpoints and servers quickly, quietly, and in a way that most monitoring tools won’t catch.
The hardened configuration is to disable clipboard redirection entirely. The CIS Benchmarks for Windows include this explicitly. If it’s been re-enabled somewhere along the way by a user who wanted the convenience, by an admin who needed it temporarily and forgot to turn it back off the exposure is real.
Interested in learning about additional real-world configuration attack paths? Watch our Video On Demand.
Configuration Drift and Compliance Risk
Beyond the direct security risk, configuration drift creates sustained compliance exposure. Most major regulatory frameworks now explicitly require not just that systems are hardened, but that hardening is maintained and change-controlled.
If you want to explore how different regulatory frameworks approach configuration hardening requirements, visit our Compliance Center, where we break down expectations across major standards, including HIPAA and FFIEC
Requirement 2.2 mandates secure configuration of all system components — removing unnecessary services, disabling insecure protocols, applying secure defaults. Requirement 6.5 goes further, requiring that any changes to those configurations go through an authorized, documented change management process. Together, these mean you need to harden systems and prove the hardening is staying in place.
HIPAA (Proposed Rule Update)
The proposed update to the HIPAA Security Rule under Section 164.312(c)(1) explicitly requires covered entities to establish a security baseline for each electronic information system — and to maintain systems against that baseline on an ongoing basis. Documentation of the baseline isn’t sufficient. You need to demonstrate continuous enforcement.
Similar language appears across FFIEC, FDIC guidelines, and various state and regional frameworks. The pattern is consistent: regulators want to see baselines defined, enforced, and change-managed — not just documented in a policy.
When an auditor reviews your environment, unapproved configuration drift is an audit finding. That has consequences ranging from remediation requirements to fines depending on the framework and the severity of the gap.
Why Drift Harder to Manage Than Patching
Patch management is a solved problem in terms of tooling and process. Vulnerability scanners continuously monitor for missing patches. Deployment tools push updates at scale. The workflow is well-established even if the execution is sometimes painful.
Configuration management at this level of rigor is harder. There are fewer tools that do it well, and the ones that exist require significant configuration themselves. Several factors compound the difficulty:
• Initial enforcement is disruptive. Implementing a full CIS Benchmark baseline on production systems isn’t a one-click operation. Configuration changes can conflict with applications, break workflows, or cause unexpected behavior. The testing and rollout process requires careful coordination between security and operations teams.
• Drift is invisible by default. Without dedicated tooling, you won’t know a configuration has changed until something breaks or an auditor finds it. Standard monitoring tools don’t cover this.
• Baselines evolve. New configuration vulnerabilities are discovered. Benchmarks are updated. What was a complete, correct baseline two years ago may have meaningful gaps today. At a minimum, baselines should be reviewed and updated twice a year.
• Every platform change is a potential drift event. OS upgrades, major patches, platform migrations — each one needs to be followed by a full re-verification of the hardened baseline.
How to Prevent Configuration Drift
Managing configuration drift effectively comes down to four things:
- Start with a recognized baseline. CIS Benchmarks and DISA STIGs are the most widely accepted. Pick the right one for your environment and use it as your reference — it’s also what auditors will compare you against.
- Automate enforcement, not just assessment. Scanning to identify drift is necessary but not sufficient. The goal is automated remediation: when a drift is detected, the system should be returned to the secure state without manual intervention.
- Monitor continuously. Configuration changes should be treated the same way missing patches are – something that gets flagged, tracked, and resolved. Not something that gets caught on the next audit cycle.
- Review your baselines regularly. Set a calendar reminder if you need to. Twice a year, review the current benchmark version against your implemented baseline and close any gaps. After any major platform change, re-verify from scratch.
Want to Learn More?
At CalCom Software, we work with organizations dealing with configuration drift every day. Watch our video-on-demand that breaks down how drift happens, how attackers use it, and how teams can maintain hardened baselines safely in production environments.
