Drift and Events

Drift & events

How drift detection works

Every backup is compared to the previous snapshot, object by object. Runtime noise (timestamps, internal ids, server-managed fields) is excluded, so a detected change means real configuration changed, not API churn.

Events

Each detected change becomes an event: add, update, or delete, with the object type, its name, and (for updates) which fields changed. The Events page is the change history of your IdP, filterable per tenant and change type. Events appear from the second backup onward, because a diff needs two snapshots.

Unbacked changes

Between backups, IdPVault polls each provider's own event log to count configuration changes that have happened since your last snapshot; that's the Unbacked changes card on the dashboard. It's a count (the detail comes from the next backup's diff), and it's your cue to run a backup if something unexpected is moving.

Why this matters

The drift lane is your unauthorized-change detector: if an admin (or an attacker) modifies a policy, removes an app, or weakens MFA rules, the next backup catches it, the event records it, and the alert tells you, with the change list in the message.