Configuration drift: when should security automation correct a change?

Security automation should correct configuration drift when the approved target state is current, the change is unauthorized, and the corrective action has been tested for the affected systems. When any of those conditions is uncertain, the response should preserve evidence and route the decision to an accountable owner.

That boundary determines whether automation removes exposure or repeatedly undoes legitimate work. A configuration difference can be an unsafe change, an approved exception, or evidence that the baseline itself needs updating. Treating all three as the same problem makes automated remediation harder to trust.

The goal is to make routine corrections automatic while keeping ambiguous changes out of an indiscriminate rollback policy.

What is configuration drift?

Configuration drift is a difference between a system's observed configuration and its intended baseline. The difference might involve a permission, service setting, firewall rule, logging configuration, or another managed property.

A useful drift finding therefore needs two things: an observed value and a valid statement of what that value should be. Without an applicable baseline, a detector can identify change but cannot establish that restoring the previous value is the right action.

NIST's security-focused configuration management guidance places security within the wider management of system configurations. Its stated goal includes reducing organizational risk while supporting required business functionality and services. That is a more useful objective than making every system identical. NIST SP 800-128.

For teams establishing their initial baseline, this related guide covers CIS benchmarking best practices. The question here comes afterward: what should happen when a running system changes?

A changed setting is not yet a remediation decision

Consider a hypothetical production service whose logging level changes during an approved investigation. A configuration policy expects the normal level. Restoring it immediately could remove the diagnostic detail the investigation needs.

Now consider the same service with security logging disabled by an unapproved deployment. Leaving that change in place could undermine visibility. Both events produce a difference from the baseline, but they require different responses.

The recommended distinction is between detecting a difference and authorizing a correction. Detection asks whether the observed state matches the expected state. Remediation asks whether a specific action is appropriate now, on these assets, under the current policy.

The decision should not depend on someone reading every alert. Encode the known cases into policy. Reserve human review for unclear ownership, conflicting requirements, untested corrections and changes with consequences that exceed the policy's authority.

Classify drift before choosing the response

The following decision table is a recommended operating model, not a vendor feature list or a formal standard.

These categories give automation an explicit route for each outcome. They also prevent an exception from quietly becoming a permanent alternative baseline.

For an exception, record the specific asset and setting rather than excluding an entire environment. Define what happens when it expires. Expiry should trigger the agreed decision or action, not an untested change to a critical service.

What makes configuration drift safe to auto-correct?

A practical policy should answer five questions before it changes a system.

Is the target state authoritative?

Identify the baseline version, the assets it applies to and the person or team responsible for it. Check whether an approved deployment or exception changes the expected value.

If two controllers disagree, repeating the correction can create a loop. For example, one deployment process may restore an application setting while a security policy repeatedly reverses it. Resolve ownership of the setting before expanding enforcement.

Does the drift still exist?

Recheck the relevant state immediately before acting where the implementation supports it. An earlier finding may no longer describe the system.

This is a documented operational concern. AWS warns that AWS Config automatic remediation relies on periodically captured compliance snapshots and can initiate remediation for resources that have already become compliant. AWS Config automatic remediation guidance.

The recommended safeguard is a precondition check in the corrective workflow. If the expected starting state has changed, stop or reevaluate rather than applying an outdated instruction.

Has the correction been tested for this scope?

Test the action on representative systems before allowing broad execution. Include the application dependencies and operating conditions that make the setting important.

Prefer a correction that can be safely repeated without accumulating unintended changes. Define its permissions narrowly. A workflow that needs to change one setting should not receive unrestricted authority merely because that is easier to configure.

What will stop a harmful rollout?

Specify failure thresholds, a pause mechanism and a recovery route before enabling enforcement. Start with a bounded group and expand only after the required checks pass.

Recovery is not always a simple reversal. If a correction interrupts access, the team may need an out-of-band path. If the prior state was insecure, automatically restoring it may also be inappropriate. Decide these cases while designing the policy, not during an outage.

How will success be verified?

Verify both the intended setting and the affected service. A completed action does not, by itself, establish that exposure was reduced without breaking required functionality.

Define the validation alongside the correction. For a logging policy, that might include checking the configured value and confirming that expected records reach their destination. For a permission change, verify the intended restriction and the authorized workflow that must remain available.

Separate monitoring from continuous enforcement

Continuous assessment does not necessarily mean continuous correction. Treat them as separate policy choices.

Microsoft's Azure Machine Configuration documentation makes this distinction explicit. ApplyAndMonitor applies a configuration and subsequently reports drift without automatically correcting it. ApplyAndAutoCorrect corrects drift when the configuration is next evaluated. Microsoft's remediation options.

Choose enforcement per setting and asset group. An understood, tested correction can run automatically. A setting tied to a sensitive dependency may remain monitored until its correction and recovery path are proven.

Monitoring should have an owner and a next step. Otherwise, it becomes a permanent queue of known exposure. Use the review to establish a supported correction, approve a bounded exception, or revise the baseline through change control.

Keep evidence of what automation changed

A compliant state answers a narrow question: does the current assessment match the policy? It may not explain how the system arrived there.

Microsoft notes that its continuous remediation mode does not report when drift was automatically corrected. Teams using that mode should account for this documented reporting behavior when designing their evidence collection. Microsoft's continuous remediation guidance.

For an auditable workflow, the recommended record connects the observed difference, policy version, authorization, execution result and post-change validation. Capture failure and exception outcomes as well as successful corrections.

Review recurring drift separately from first-time findings. If the same setting keeps returning to an unsafe value, another process may be recreating it. Correct the source of that change instead of counting every repeated repair as independent progress.

Frequently asked questions

Is configuration drift always a security problem?

No. A difference from a baseline can reflect an authorized change, a temporary exception or an unsafe modification. Evaluate the applicable baseline and change authorization before deciding whether to correct it.

Should every configuration drift finding be remediated automatically?

No. Automatic correction is appropriate when policy authorizes a tested action against a current, applicable target state. Route ambiguous changes and untested high-impact actions to review. Once those cases are understood, encode the repeatable decisions into policy.

What is the difference between drift detection and drift remediation?

Detection identifies a difference between observed and expected configuration. Remediation changes the system to address that difference. A complete workflow also verifies the result and checks that required functionality remains available.

How can teams prevent automation from undoing approved changes?

Keep baseline versions, approved changes and exceptions aligned with enforcement. Give each setting a clear owner and ensure competing controllers do not enforce incompatible values. Test the exception path as carefully as the automatic correction path.

Put one recurring drift finding under a clear policy

Choose a recurring configuration change your team already understands. Define its authoritative target, permitted scope, exception conditions, corrective action and validation. Test it on a representative group, including a case where the system has changed since the original finding.

Expand enforcement when those checks hold. The useful measure is whether the policy repeatedly restores the intended security state while preserving required service, not how many alerts disappear.