I woke up to every member of the password manager being suspended. Nobody could access any vaults. The SCIM bridge — the thing that syncs users between the identity provider and the password manager — had decided to suspend everyone.
What Happened
The SCIM bridge syncs users from identity provider groups into the password manager. If a user exists in the password manager but isn’t in any of the synced groups, the bridge suspends them.
Someone changed the group configuration. The source groups were either empty or pointed at the wrong set. The bridge ran its sync, saw zero users in the source, and concluded that every existing member should be suspended.
It did exactly what it was told to do.
The Blast Radius
Every engineer, every team, every shared vault — locked out. Service accounts that used the password manager for credential retrieval stopped working. CI pipelines that pulled secrets via the Connect server started failing.
The Fix
Re-adding users to the correct groups and triggering a re-sync restored access. The bridge saw them again in the source and un-suspended them. No data was lost — the password manager suspends but doesn’t delete.
The Guardrails I Added
The real fix was preventing this from happening again:
- Dedicated SCIM groups — separate from permission groups. Don’t reuse groups that people actively modify for other purposes.
- Minimum user threshold — if the sync would suspend more than N% of users, abort and alert.
- Dry-run first — log what the sync would do before it does it.
Takeaway
SCIM bridges are deletion machines that run on a timer. If the source goes empty — misconfigured group, API error, rate limit — the bridge interprets “zero users in source” as “suspend everyone.” Always have guardrails on the sync side, not just the source side.