They need to distinguish authorised autonomous behaviour from uncontrolled drift. A moving baseline is not the same as no baseline, but it does require policy-defined expected behaviour, event-level logging, and reconciliation against declared operating patterns rather than static snapshots alone.
How to tell a moving baseline from unauthorized change
A moving baseline is normal when the system is meant to adapt, but it still needs a declared operating pattern that security can test against. The practical question is not whether the state changed, but whether the change matches approved behaviour, expected timing, and known control limits. That means the baseline must be explicit enough to measure, not just observed after the fact.
Teams detect unauthorized change by comparing live behaviour against policy-defined expectations, then asking whether the change was authorised, bounded, and logged. Static snapshots are useful only as a reference point; they miss drift in systems whose state legitimately evolves. The control objective is to separate sanctioned adaptation from unapproved deviation before the deviation becomes normalised.
That is why baseline management and detection engineering have to work together. A baseline that changes without governance becomes drift; a baseline that never changes becomes blind to real operational shifts. Good detection uses declared behaviour, versioned policies, and reconciliation logic so the team can see what changed, when it changed, and whether the change was within tolerance.
What evidence makes the distinction reliable?
Reliable detection depends on event-level logging, not only periodic configuration checks. Teams need records that show the action, the actor or process that caused it, the time window, and the policy context that made it acceptable or unacceptable. Without that chain, a legitimate automation step can look like tampering, and a malicious alteration can look like ordinary drift.
Reconciliation is the other half of the evidence model. Security teams should compare current state to the declared operating pattern, then confirm whether the difference is explainable by an approved workflow, a scheduled update, or a documented exception. Where the difference cannot be explained, the default assumption should be that the change is unauthorized until proven otherwise.
For infrastructure and platform teams, hardened baseline references help anchor that comparison. CIS Benchmarks are useful here because they provide prescriptive hardening baselines that teams can adapt into their own declared operating patterns, rather than relying on vague “known good” images.
Why moving baselines create detection blind spots
The main failure mode is normalisation. When a system changes frequently, teams can stop noticing incremental deviations because each change looks like part of the ongoing evolution. Attackers benefit from that uncertainty, especially when they can hide in routine maintenance, feature rollout, or automated remediation activity.
Another blind spot appears when teams only compare against the last approved snapshot. That approach works for static systems, but it breaks down when the expected state is itself dynamic. Current guidance suggests detecting drift against policy, operating intent, and observable behaviour together, so the team can distinguish a sanctioned transition from an unexpected one.
Frameworks that emphasise continuous detect-and-respond thinking reinforce that approach. NIST Cybersecurity Framework 2.0 is helpful for organising detection around ongoing governance, continuous monitoring, and response rather than one-time validation. For adversary behaviour and drift that may accompany compromise, MITRE ATT&CK Enterprise Matrix helps teams map suspicious change to known tactics such as credential access, persistence, and lateral movement.
Risk and Threat Considerations
Moving baselines create a real detection risk because the organisation may stop knowing what “normal” means at the moment it most needs to know. If authorised automation, scheduled change, and attacker activity all produce similar signals, teams can miss malicious drift or over-trust an altered state that has never been formally re-approved.
Failure mechanism: The baseline is updated faster than the control evidence that should justify it, so drift becomes indistinguishable from sanctioned change.
Impact: Unauthorized change can persist longer, alert quality degrades, and incident responders lose confidence in whether the current state is safe enough to continue operating.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Baseline drift often follows changes to privileged accounts and automation identities. |
| Recommendation — Review account changes that can alter baseline behavior and remove unnecessary standing access. | ||
| NIST CSF 2.0 | DE.CM-01 — The organization monitors networks and network services for potential cybersecurity events | Moving baselines require continuous monitoring to spot unauthorized deviations from expected behavior. |
| GV.RM-01 — Risk management strategy is established and communicated | A moving baseline only works when the organization defines what change is acceptable and who approves it. | |
| Recommendation — Monitor live state continuously so changes outside declared operating patterns are flagged quickly. Set clear approval rules for adaptive change so drift is judged against policy, not snapshots alone. | ||
| MITRE ATT&CK | T1070 — Indicator Removal on Host | Attackers may hide unauthorized change by erasing or suppressing evidence of what happened. |
| Recommendation — Hunt for missing logs and evidence suppression when state changes without a matching change record. | ||
Practitioner Guidance
What to prioritise: Define the expected behaviour first, then decide which changes are allowed to self-update and which require human approval. If the system can alter its own operating pattern, the approval boundary must be explicit enough that analysts can tell intended adaptation from scope creep.
What to verify: Confirm that logs capture the change event, the initiating identity or process, the policy decision, and the before/after state. If any of those elements are missing, the control is not strong enough to prove that a moving baseline stayed within bounds.
Practitioner takeaway: The goal is not to freeze the baseline, but to make every legitimate change explainable in evidence so that uncontrolled drift stands out immediately.