A privileged control plane
Support and recovery workflows can replace authenticators, change contact channels, impersonate users, grant temporary roles, add federation trust, bypass normal policy, or restore service. They are security control planes, not administrative convenience.
The effective assurance of an account cannot exceed the easiest workflow that can transfer its control.
Define permitted actions
List each support action by target resource, required evidence, operator role, requester identity, independent approval, delay, notification, expiry, and audit. Separate diagnosis from authority to change state. Give support tools named actions instead of broad administrator consoles.
Use known channels and current authoritative records. Do not accept caller-supplied contact information, biographical facts, or possession of a compromised mailbox as complete proof for a high-assurance reset.
Bind and contain changes
Bind approval to the exact account, authenticator, device, role, route, and lifetime. Notify through an independent channel. Revoke or review old authenticators and sessions. Limit how much one operator can change and require a second party for high-impact identities or trust configuration.
Make exceptions expire automatically. Record the old and new state, evidence, operator, approver, reason, ticket, and downstream effects.
Failure and residual risk
Attackers can learn procedures through early calls and exploit them later. Executive urgency and support empathy can create exceptions. A compromised operator account can perform valid-looking changes. Two operators can collude. Delays and strict checks can block legitimate recovery during an incident.
Recovery data and audit records can contain sensitive identity information. Minimize access and retention while keeping enough evidence for investigation.
Pomerium boundary
Pomerium trusts the configured identity provider's later authentication result. A support reset at that provider can therefore grant a valid Pomerium session. Pomerium can protect support tools and require policy for their routes, but the provider and application owners must constrain each support action, authenticator change, impersonation, and emergency grant.
Evaluation checklist
- Which support action can replace identity proof, authenticator, policy, federation, session, or application authority?
- Is verification independent of attacker-supplied contacts, discoverable facts, and the compromised channel?
- Are operator authority, approval, target, duration, notification, and downstream revocation narrowly bound?
- Can one urgent story, operator account, or emergency mode transfer complete control?
- Does legitimate recovery remain available, accessible, time-bounded, and fully evidenced under outage conditions?
