Prompt for MFA at every login path, including APIs and mobile apps, and again for sensitive actions such as changing a password or email, disabling MFA or elevating to an admin session. Always require it for administrators. Use risk signals to ask more often, not to skip it where it is needed.
Where OWASP says to prompt
From the MFA cheat sheet:
- at every login path, including APIs and mobile apps
- when changing a password or security questions
- when changing the account email
- when disabling MFA
- when elevating to an admin session
- always for administrative and other high-privilege users
A common bug is protecting the web login while the mobile API or a legacy endpoint accepts a password alone. Test each entry point.
Step-up for risky moments
Step-up means asking again, mid-session, before a high-risk action. OWASP's credential stuffing guidance mentions it for large transactions and administrative changes. Typical triggers: exporting data, adding a payout account, creating an API key, inviting an admin, changing SSO settings.
Risk-based prompts
OWASP lists signals such as geolocation, IP reputation, device fingerprinting, time of access, behaviour and known compromised credentials. Responses range from asking for an extra factor to re-authentication, to denying access and alerting. Developers must make sure the signals cannot be spoofed. Do not treat location or behaviour as a factor itself. OWASP says they inform risk but are not factors.
Avoid prompt fatigue
Prompting too often trains users to approve anything. Prefer phishing-resistant methods that do not rely on tapping approve, and use number matching if you do use push. See push fatigue and number matching.
Pair it with session rules
A fresh MFA result should shorten the risk window, not extend it. Combine with sensible timeouts from session timeouts and logout.
Implementation checklist
- List every endpoint that accepts credentials.
- List actions that should trigger step-up.
- Require recent MFA, for example within a short window you choose.
- Notify the user on MFA changes.
- Log every step-up result.
- Test downgrade paths. See MFA recovery.
Measure the effect on users. Track how often step-up prompts appear, how many fail, and how many support tickets they create. If a particular action prompts constantly with a very low failure rate, consider whether it really is high risk. If an action never prompts but sits behind sensitive data, add it. Tune the list over time rather than guessing once, and record the reasoning so the next reviewer understands it.
Quick check
Is MFA only for login?
No. Sensitive changes inside a session also deserve a fresh check.
Can risk signals replace MFA?
They decide when to ask for more. OWASP says they do not count as a factor.
Sources
Last reviewed: 19 October 2026.
