Secure Support and Recovery Workflows

Protection need

Support must restore legitimate work without becoming an easier takeover or authorization path. Inventory password reset, authenticator enrollment and removal, recovery contact change, account linking, unlock, impersonation, session revocation, temporary role, policy exception, federation change, data export, and emergency access.

Classify each action by maximum effect. Separate proof of account control from proof of real-world identity, current employment, role, device custody, and authority for the requested change.

Security objectives and requirements

For each action define requester evidence, operator role, independent source, approver, delay, notification, permitted target, expiry, revocation, and audit. Use stronger steps for changes that can replace phishing-resistant authentication, add federation trust, impersonate a user, or grant privileged access.

Require operators to select typed actions, not use a general administrator console. Bind the request to the exact account, authenticator, role, resource, and duration. Use known contact data from an authoritative source and do not update that source within the same verification.

Provide an accessible alternative path for lost devices, people with disabilities, unavailable channels, and genuine emergencies. The alternate path must have its own bounded assurance and must not become a permanent bypass.

Security invariants and evidence

• No support operator can both assert the request evidence and approve a high-impact change.
• Caller-supplied contact or biographical knowledge is not enough for high-assurance recovery.
• Replaced authenticators, active sessions, recovery codes, and delegated authority are revoked or explicitly reviewed.
• Every temporary grant and exception expires without manual cleanup.
• Independent notification names the change and a safe reversal or report path.
• Evidence records old state, new state, operator, approver, authoritative inputs, time, reason, ticket, and downstream effects.

Failure cases

• An attacker calls once to learn the process and later supplies the expected answers.
• A compromised mailbox receives both recovery and notification.
• An operator uses a broad console to add an attacker authenticator without action-level evidence.
• Executive urgency overrides the second approval.
• An identity-provider recovery revokes no Pomerium or application sessions.
• A break-glass role remains after the incident.
• A strict workflow blocks a legitimate user and support creates an undocumented shared account.

Response and recovery

On suspicious support activity, freeze further changes, preserve evidence, revoke operator and target sessions, remove newly enrolled authenticators and trusts, rotate affected credentials, and review application actions performed after the change. Notify the user through an independent known channel.

Recover the support system itself from a compromised operator, ticket system, identity provider, or directory. Keep an offline or separately controlled way to revoke privileged support authority.

Design tradeoffs and residual risk

Delay and dual control reduce rapid takeover and can extend outage. More identity evidence can increase privacy exposure. Self-service reduces operator risk and depends on pre-enrollment and device custody. Central support improves consistency and creates a high-value control plane.

Collusion, coercion, compromised authoritative sources, and valid operator misuse remain. Assign monitoring and response that do not rely on the same operator group.

Pomerium boundary

Pomerium can protect support and administrative routes and log covered access. The identity provider owns account and authenticator state. Applications own impersonation, object roles, exports, and session state. A provider reset can create a valid Pomerium session, so containment must span provider, Pomerium, and upstream applications.

Exercise

Build a support action matrix for one production identity domain. Test password reset, passkey replacement, recovery-channel change, session revoke, temporary admin, impersonation, and federation change.

Run four cases: convincing external social engineering, compromised support account, provider outage, and legitimate recovery without the primary device. Measure completion time, denied attacker actions, notifications, session revocation, expiry, and evidence. Remove any general operator permission not needed by the typed actions.

Evaluation checklist

• Does every support action have a maximum effect, risk tier, evidence, operator, approver, target, expiry, and revocation plan?
• Are verification facts independent of the requester and the channel assumed compromised?
• Can one operator or console transfer full account, federation, policy, or impersonation authority?
• Does containment revoke identity-provider, Pomerium, application, and delegated state?
• Can legitimate recovery finish during device loss, outage, accessibility need, and emergency without a permanent bypass?