Control objective
Reauthentication requires the claimant to prove control of an authenticator again. Step-up authentication requires a stronger method or assurance than the current session provides. Use them when session age, changed risk, or a sensitive action makes the existing evidence insufficient.
Trigger and bind the ceremony
Define triggers such as password or authenticator change, payment approval, privilege elevation, policy administration, account recovery, suspicious activity, or a maximum session age. Bind the successful ceremony to the same account, client transaction, intended action, and short validity period.
Preserve the requested action
After reauthentication, return to a server-held representation of the original action. Do not trust altered client parameters. Re-run authorization because fresh authentication does not grant new permission. Record the method, time, action, and result.
Failure and residual risk
A session attacker can initiate step-up and socially engineer the user. A weak fallback can defeat the stronger method. Excessive prompts cause fatigue and unsafe workarounds. Reauthentication does not repair a compromised endpoint or incorrect authorization.
Pomerium boundary
Pomerium uses the configured identity provider for user authentication. An application that needs fresh or stronger authentication for a business action must design that requirement with the provider and session flow. Route access and application action approval remain separate decisions.
Evaluation checklist
- Which action or risk change requires fresh or stronger authentication?
- Is the ceremony bound to the same account, action, and transaction?
- Does authorization run again after authentication?
- Can fallback or recovery provide a weaker bypass?
- Are prompt frequency, failure behavior, and evidence appropriate?
