Configuration drift

Drift needs two things: a known good state and a way to see when reality no longer matches it. Changes that cause it are usually small and well meant. An admin turns off a policy to fix a support ticket, a project asks for an exception, or a new feature arrives with its own default.

Where each platform records or detects change

• Microsoft 365 and Entra: the Entra audit logs record changes to policies, roles and apps, so you can see who changed what and when.
• Azure: Azure Policy evaluates resources against rules and shows which ones are non-compliant, and it can block or flag new resources that break a rule.
• Google Cloud: Cloud Asset Inventory keeps a history of resource and policy metadata, so you can compare a resource over time.
• AWS: AWS Config records configuration changes of supported resources and evaluates them against rules.

Two ways to catch it

Event-based detection reacts to a change as it is logged. Scan-based detection re-runs the checks on a schedule and compares the result with the previous run. Event feeds are fast but narrow. Scheduled scans are slower but find anything that fails the standard, however it got there.

Whichever you use, the output has to say what changed and since when. "Forty failing controls" is a number; "this control passed on Monday and fails today" is something an admin can act on.

A one-time review gives a snapshot. Cloud environments change daily, so the snapshot ages quickly. NIST's guide to configuration management (SP 800-128) treats monitoring for unauthorised or untracked change as a core part of managing a secure configuration, not an optional extra.

The risk is that drift is silent. A conditional access policy switched to report-only, a storage account opened for a test, or an extra Global Administrator added during a migration can stay unnoticed for months. Because nothing broke, nobody looks.

Take a simple case. During a migration weekend, a team adds two more Global Administrators so that work can go faster, and relaxes a sign-in policy for a legacy system. The migration finishes, the project team moves on, and the temporary changes become the permanent state. A review that compares today's results with the last known good run shows exactly those two differences.

Drift also weakens any report you give to customers or auditors. A report is only as good as its date, so you need to know whether the state has held since.

1. Fix a baseline first. You cannot detect drift from a state you never defined, so run a full assessment and resolve or document each failing item.
2. Decide who gets told when something regresses and how fast they must respond. A finding nobody reads is not detection.
3. Turn on the native audit logs for each platform and check how long they are kept.
4. Re-scan on a schedule that suits how fast your environment changes. The shorter the gap between scans, the sooner a regression is found.
5. When a control regresses, find out why. A recurring cause, such as a support workaround, is the thing to fix.

ConfigCobra's monitoring module scans continuously and detects drift, and it alerts you when a control regresses. It is available on Microsoft 365, Azure, Google Cloud and AWS.

• The scheduler runs scans daily, weekly or monthly, for any combination of controls or for predefined rule sets.
• Email notifications go out for findings and drift.
• Policies only alert and suggest a fix, as a script or portal steps. ConfigCobra is read-only and never changes a tenant.