Design step-up checks for risky logins and account changes

A customer signs in from a new phone while traveling. Another account sees a new environment immediately followed by a recovery-email change.

The useful question is what happens next.

Both events may contain a new-device signal. A step-up policy should examine the attempted action and the supporting evidence before choosing a response.

Use the OWASP authentication guidance to review where reauthentication belongs. Then attach device and network observations to the action being protected. Keep the route for the real owner to finish that action as carefully designed as the detection rule.

Choose the protected transitions

List login, recovery, email changes, new authenticators, payment changes and other high-impact actions your product supports. Decide which existing proof of account control is sufficient for each transition and where stronger confirmation may be needed.

A rule that protects login but leaves recovery unexamined can fail to protect the account. The reverse can create repeated friction while doing little about an already compromised session. Review the journey as a connected set of transitions.

Keep the evidence and the action separate

This is an example review table, not a universal policy or a vendor’s built-in threshold. Adapt it to the product’s actual authentication and recovery options.

Treat a privacy exit as context

IP-derived location can change when a VPN or relay changes the visible connection. Do not translate distance directly into physical movement. Correlate the apparent jump with device continuity, authentication and subsequent account actions.

The VPN hub covers that distinction. A known environment and an unfamiliar exit can be a routine network change. An unfamiliar environment changing important account settings deserves a more specific examination.

Make the challenge finishable

Preserve the original action while requesting the stronger check. Explain the required step, avoid repeated challenges after success and provide a route for a customer who has lost an authenticator. The fallback must also protect account ownership; it should not automatically weaken the original requirement.

Passkeys and other Web Authentication mechanisms can strengthen authentication. W3C’s Web Authentication specification describes that technology. They do not remove the need to review recovery, active sessions and authorization for sensitive actions.

Plan what happens after confirmed takeover

A detection event is not the end of the response. Identify the sessions and credentials that need revocation and the recovery actions available to the owner. Record what was changed, when access ended and which important settings need to be checked.

OWASP’s session management guidance provides a reference for reviewing the session boundary. Test the application’s behavior directly: a revoked session should no longer authorize the protected action.

Evaluate the complete journey

Use controlled accounts to test a normal network change, a new device with valid authentication, an unusual recovery change and a revoked session. Confirm that your team can reconstruct each event and that the customer can complete or recover the legitimate action.

Measure repeated challenges, completion, support contacts, confirmed unauthorized access and reversed restrictions. A growing number of alerts is not a measure of safer accounts. The account takeover hub connects these checks to the tools and evidence used in a pilot.