What Is Configuration Drift, and Why Is It a Problem?

Back in the day, I managed IT for a chain of banks. And if you've ever worked in banking, you know there are a few things banks aren't exactly short on: regulations, audits, and security requirements. 😂

A big part of my job was making sure our systems were configured the way they were supposed to be. When a new workstation was deployed, we'd configure it, apply the required security settings, validate everything, and send it out into the world.

As far as I was concerned, that machine was good.

Then audit time would roll around, and an auditor would check one of those same settings and find that it wasn't configured correctly anymore.

"That's weird. I KNOW we set that."

So we'd fix it. Then they'd find another one. And another one.

Now I'm digging through documentation, checking Group Policy, comparing machines, asking technicians if anyone changed something, and trying to figure out how a workstation that I knew was configured correctly when it left my hands was suddenly no longer configured correctly.

Sometimes there was an obvious answer. A technician changed something while troubleshooting. Software was installed. A policy changed. An update happened.

Other times?

¯\(ツ)/¯

The important lesson for me wasn't that we were configuring machines incorrectly.

It was that configuring something correctly once didn't mean it stayed configured correctly.

At the time, I didn't spend much time calling that problem configuration drift. I mostly called it "Why the hell did this change?"

But that's exactly what it was.

Configuration drift is when the actual state of a system no longer matches the state you intended or approved.

And despite the name, drift doesn't have to happen slowly. A machine can remain perfectly configured for three years, or it can drift five minutes after you deploy it.

That's what makes drift such an interesting security problem. We spend a tremendous amount of effort figuring out how to set security configurations.

The harder question is: How do you know they're still set?

So What Actually Causes Drift?

The frustrating answer is: a lot of things.

Drift isn't necessarily a sign that somebody screwed something up. Endpoints are constantly being changed by users, administrators, software, management platforms, and Windows itself. Any one of those changes can move a configuration away from the state you originally approved.

Some common causes include, but definitely aren't limited to:

• Windows Updates and Feature Updates: Updates can introduce new functionality, change defaults, replace components, or otherwise affect existing configurations.
• Third party applications: Installers and applications can modify registry values, services, firewall rules, permissions, browser configurations, and other local settings.
• Rogue or overly privileged users: A user with sufficient permissions can intentionally or unintentionally change security settings.
• System or policy corruption: Files, registry values, local policy data, or other components can become damaged or inconsistent.
• Troubleshooting that never really got turned back on: Someone disables a security control to troubleshoot a problem, fixes the problem, closes the ticket, and forgets about the temporary change. Temporary has an amazing ability to become permanent in IT. 😂
• Group Policy changes: GPOs get modified, removed, reassigned, fail to apply, or conflict with something else managing the endpoint.
• Intune/MDM changes: Policy assignments, exclusions, configuration changes, or competing management methods can alter the endpoint's actual state.
• RMM scripts and automation: A script written three years ago can still be happily changing configurations long after everyone has forgotten why it exists.
• Security products: EDR, AV, firewalls, and other security software may modify local settings as part of their own configuration or remediation.
• Application updates: It's not just installing new software. An existing application's update can change services, permissions, registry values, or other configurations.
• Administrative changes: Sometimes somebody simply makes a change and doesn't document it, doesn't realize what else it affects, or doesn't know another system is supposed to manage that setting.
• Malicious activity: An attacker may deliberately weaken controls, disable protections, create exclusions, change logging, or otherwise modify the security configuration.

And sometimes the answer is simply:

"We don't know."

That's part of what makes drift so important. The cause is useful to understand, but drift describes the result, not the cause.

Whether Windows changed it, an application changed it, Bob from Accounting changed it, or a technician changed it at 4:45 on a Friday, the important part is that the endpoint no longer matches the security state you intended.

Why Is Drift Such a Problem?

Most organizations are pretty good at deploying configurations. The harder question is whether those configurations actually stayed that way.

Let's say you harden 500 endpoints today. Everything looks beautiful. You've applied your security policies, checked your configurations, and maybe even collected the evidence you need for an audit.

What happens tomorrow? Or six months from now?

If a technician changes a security setting on one machine to troubleshoot an application, how do you know? If an update changes behavior across 50 machines, who notices? If a policy stops applying to a laptop, does anything actually tell you?

This is where I think there's an important distinction between deployment and validation.

Pushing a configuration tells a machine what you want. Validating the configuration tells you what you actually have.

Those aren't always the same thing.

That's why drift matters for both security and compliance. Passing an audit on Tuesday doesn't magically mean those systems are still configured the same way on Friday. A screenshot, policy assignment, or successful deployment can prove that something was configured at a point in time. It doesn't necessarily prove that the expected state still exists today.

The question shouldn't just be "Did we harden our endpoints?"

It should also be "Are they still hardened?"

Because security isn't just setting the right configuration once. It's knowing that the configuration you intended is still the configuration you're actually running.

That's why drift detection isn't just a compliance feature. It's a visibility problem.

You can't protect a security configuration you don't realize has changed.

And if your current answer to "Are our endpoints still configured the way we approved them?" is "They should be..."

You might want to go check. 😂

— Hardening with Robbz