The control breaks when it assumes factor completion equals identity verification. OTPs, push prompts, and security questions can be phished, intercepted, or coerced, so the attacker only needs to defeat the factor event, not prove legitimate identity. In high-risk flows, that leaves the organisation with stronger friction but not stronger assurance.
Where the control model fails
Risk-based authentication only works when the system can distinguish a legitimate authentication event from a merely completed factor challenge. If the decision engine still treats OTP entry or a push approval as strong evidence, it is measuring participation in the challenge, not proof of the person or process behind it. That gap is why attackers focus on MFA fatigue, relay, phishing, and token theft rather than password guessing.
A stronger risk score does not fix a weak authenticator. In practice, the control degrades into step-up friction that is still bypassable through MFA bypass patterns such as OTP relay and push bombing, so the organisation gets more prompts without materially stronger assurance.
When the flow is sensitive, the right question is not whether the user completed an OTP or push prompt, but whether the method resists phishing, replay, and coercion under the exact attack conditions you expect. That is why workforce identity guidance increasingly treats phishing-resistant methods as the baseline for step-up decisions rather than assuming any second factor is equally strong.
Why OTPs and push approvals remain weak signals
OTPs and push approvals are useful for reducing password-only abuse, but they do not automatically create a high-trust authentication outcome. OTPs can be phished in real time, intercepted through adversary-in-the-middle kits, or relayed into the target session. Push approvals are vulnerable to user habituation, notification fatigue, and social engineering that gets the user to tap through a prompt they did not initiate.
The core flaw is that these methods prove possession of a channel or device event, not durable binding to the actual login transaction. The attacker does not need to break the whole identity system, only the factor event itself. That is why NIST SP 800-63 Digital Identity Guidelines place different assurance expectations on authenticators and emphasise phishing-resistant approaches for stronger assurance.
Risk-based authentication becomes especially fragile when it uses OTP or push completion as a shortcut for “low enough risk.” In that design, the risk engine may still challenge a suspicious login, but the challenge is not materially harder to satisfy than the original password prompt. The result is a control that changes the user experience more than the attacker’s workload.
What a better step-up decision should be measuring
A high-value step-up control should key off whether the authenticator is resistant to phishing, replay, and remote approval abuse, not whether the user can respond quickly to a prompt. For high-risk flows, the control should prefer phishing-resistant methods, device-bound authenticators, or stronger transaction-specific verification instead of treating OTP or push completion as sufficient proof.
Practitioners should align the decision with the asset and action at risk. If the login unlocks admin access, financial transactions, recovery paths, or other high-impact actions, then the authenticator must reduce attacker leverage, not merely add inconvenience. Passwordless and passkeys guidance is relevant here because it shows how phishing-resistant sign-in changes the assurance level of the step-up itself.
For identity teams, the operational test is simple: if an attacker can satisfy the step-up while already in the middle of a phishing or relay flow, the control is not giving you the assurance you think it is. In that case, the risk model needs to treat OTP and push as legacy compatibility controls, not as the decisive factor for high-risk access.
Risk and Threat Considerations
When OTPs and push approvals are used inside risk-based authentication, the main exposure is false confidence. The organisation may believe it has adaptive protection, while the attacker is still able to complete the challenged login through relay, fatigue, or coercion. That matters most in sensitive workflows because the control can be bypassed without needing password reuse or malware on the victim host.
Failure mechanism: The authentication engine scores context, but the step-up factor is still easy to complete remotely or under pressure, so the control accepts a completed challenge as though it were robust identity proof.
Impact: Attackers gain access to privileged or sensitive functions, and defenders may miss the compromise because the login appears to have passed policy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Sets assurance expectations for authenticators and step-up authentication in this exact scenario. |
| Recommendation — Use phishing-resistant authenticators for high-risk step-up decisions instead of OTP or push-only approval. | ||
| OWASP ASVS | V6 — Authentication | Authentication assurance and factor strength are central to whether step-up actually proves identity. |
| V10 — OAuth and OIDC | Federated sign-in and step-up flows often depend on token and authenticator choices that affect assurance. | |
| Recommendation — Require stronger authentication methods for sensitive flows and verify factor resistance to phishing and relay. Validate that your sign-in flow binds the user to the transaction rather than accepting a weak factor event. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Organisational user authentication strength is the control family most affected by weak OTP/push step-up. |
| IA-5 — Authenticator Management | OTP and push approvals are authenticators whose lifecycle and strength determine the control outcome. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Customer and external-user risk-based step-up flows face the same weak-factor problem. | |
| Recommendation — Strengthen organisational authentication so high-risk access cannot be satisfied by weak factor completion alone. Manage authenticators so high-risk access can require stronger, phishing-resistant factors. Apply stronger external-user authentication where risk-based step-up is protecting sensitive actions. | ||
Practitioner Guidance
What to verify: Confirm that your step-up policy distinguishes between “factor completed” and “factor resistant to phishing or relay.” If the same OTP or push option is allowed for high-risk and low-risk actions, the policy is probably too blunt for the environments you are trying to protect.
Decision rule: If the access path can reach admin consoles, recovery actions, payment changes, data export, or session reauthentication for critical systems, require a phishing-resistant method or a stronger transaction-specific control instead of allowing generic OTP or push approval.
Common mistake: Teams often tune the risk engine and leave the authenticator unchanged. That makes the control look adaptive while the attacker’s job barely changes, which is why modern authentication guidance and application security verification guidance both push toward stronger authentication assurance for high-value actions.
Practitioner takeaway: Risk-based authentication is only as strong as the step-up method it can demand, so OTPs and push approvals should be treated as lower-assurance fallback options, not the primary safeguard for high-risk access.
Related resources from NHI Mgmt Group
- What breaks when multi-factor authentication still relies on SMS codes or push approvals?
- Why do passwords, OTPs, and push approvals still leave customer accounts exposed to takeover risk?
- Why do OTPs and push approvals still leave MitM risk in place?
- Why do ephemeral credentials still leave risk in machine access models?