auditing-break-glass-account-trustlisted

# Auditing break-glass account trust: the last-resort key must be sealed, watched, and rare A break-glass account exists for the emergency where normal admin access is broken, the identity provider is down, everyone is locked out, so it holds the highest privilege and, by design, bypasses some of the controls that gate everyone else. That combination, maximum power plus fewer gates, is precisely why it is dangerous when its own controls are loose. The account is supposed to be a sealed last resort: strong unique credential, rotated after each use, covered by logging and alerting, used rarely and reviewed every time. The failures are where it stops being sealed. A static, shared, or never-rotated credential turns the emergency key into a permanent superuser login anyone who once saw it can use. An emergency account excluded from the multi-factor, conditional-access, and logging controls that cover other admins is both easy to use and invisible when used. A just-in-time or privileged-access-management elevation that grants more than the task needs, or is not revoked when the task ends, leaves standing privilege behind a temporary label. An emergency path with no approval, no time bound, and no alerting gets used routinely instead of exceptionally. And a break-glass use that triggers no review means the one time it mattered, nobody looked. The audit checks that the emergency identity is sealed, watched, minimally scoped, and reviewed, so its power is available in a real emergen