Control objective
Account recovery restores access after an authenticator is lost, unavailable, or suspected compromised. It must verify the subscriber with assurance suitable for the account and must not become an easier takeover path than normal authentication.
Recovery design
Provide pre-enrolled recovery codes, multiple bound authenticators, verified help-desk procedures, or renewed proofing as appropriate. Bind the recovery to the intended account. Limit attempts. Notify the subscriber through an independent channel. Revoke or review lost authenticators and active sessions.
High-impact changes
Adding an authenticator, changing recovery channels, or replacing a phishing-resistant method can transfer control of the account. Require recent strong authentication or a controlled recovery process. Add delay or independent review for high-impact accounts when the risk supports it.
Failure and residual risk
Email and SMS recovery can inherit mailbox, telephone, and social-engineering weaknesses. Knowledge questions often rely on discoverable facts. Help desks can be pressured into exceptions. Recovery that remains permanently available expands the attack surface.
Pomerium boundary
The identity provider owns user account recovery. Pomerium trusts the provider's later authentication result. Operators must review provider recovery policy because a recovered provider account can create a valid Pomerium session. Application-local accounts can have separate recovery paths.
Evaluation checklist
- Does recovery provide assurance suitable for the protected account?
- Can one compromised email, phone, or help-desk interaction take over the account?
- Are authenticator changes and recovery events attributable and notified?
- Are old authenticators and sessions revoked or reviewed?
- Is recovery tested for both availability and attack resistance?
