Risk-based authentication reduces MFA fatigue in zero trust

At a glance

What this is: This article argues that risk-based authentication can reduce MFA fatigue by replacing constant prompts with context-aware decisions that challenge only when risk is high.

Why it matters: For IAM and security teams, the practical issue is not whether MFA exists, but whether it is tuned well enough to protect privileged and routine access without driving users into unsafe workarounds.

👉 Read Unosecur's analysis of risk-based authentication and MFA fatigue

Context

Risk-based authentication is a way to decide whether an access request should be allowed silently, stepped up, or denied based on current risk signals. In this article’s framing, the problem is not lack of authentication, but authentication overload that weakens the control through user fatigue, exemptions, and workaround behaviour.

Zero Trust programs often fail operationally when every session is treated as equally suspicious. That creates prompt fatigue, especially where privileged users, legacy apps, or weakly scoped exceptions keep the same people outside the intended control boundary.

The identity governance issue is broader than login friction. Teams need assurance that authentication controls can be measured, tuned, and defended as part of human IAM, because a noisy control is often a weak control in practice.

Key questions

Q: What breaks when MFA prompts and access checks create authentication fatigue?

A: When prompts become repetitive, people stop paying attention and may approve requests without thinking. The article links this to alert fatigue, mindless approvals, and workarounds that weaken control effectiveness. The failure is not MFA itself, but overuse without context. Continuous, contextual authorization can reduce unnecessary interruptions and keep users engaged with the decision at hand.

Q: How should security teams implement risk-based authentication in a Zero Trust environment?

A: Security teams should use risk-based authentication to verify identity continuously, not only at initial sign-in. Combine device posture, location, network, user behavior, and resource sensitivity to assign a live risk score. Increase authentication requirements when signals look unusual, and allow low-friction access when risk is low. The goal is to keep access decisions context driven and adaptive.

Q: How should security teams measure whether authentication controls are actually working?

A: Measure the full path, not just successful login. Teams should track completion rates, latency, recovery effort, suspicious attempts, and downstream fraud or support load. For NHIs, add provisioning, rotation, revocation, and offboarding completion. If the metric does not change a control decision, it is not yet useful for governance.

Q: Should organisations prioritise prompt reduction or stronger checks first?

A: They should do both in sequence. Start by removing unnecessary prompts from low-risk flows, then concentrate stronger checks on privileged actions and unusual sessions. If you harden everything first, users resist. If you only reduce prompts, assurance drops. The right balance is selective friction where the risk justifies it.

Technical breakdown

How risk-based authentication changes the decision path

Risk-based authentication, or RBA, evaluates each login request in real time and selects one of three outcomes: allow, step up, or deny. It uses context such as user role, device health, location, behaviour, and resource sensitivity to avoid treating all access as equal. In practice, that means a known user on a managed device may pass quietly, while a privileged request from an unfamiliar network may trigger stronger proof such as a phishing-resistant step-up. The architecture is less about adding more checks and more about moving the check to the moments that matter.

Practical implication: Define the signals that drive allow, step-up, and deny decisions before expanding policy scope.

Why MFA fatigue turns a security control into a user-workaround problem

MFA fatigue happens when users are challenged so often, or so badly timed, that they begin to ignore prompts, seek exceptions, or approve requests reflexively. The control problem is not authentication strength alone, but the frequency and precision of challenges. Blanket prompts, legacy protocols, and exception-heavy designs create a predictable path to fatigue. Once that happens, the organisation loses both security signal and user trust, because people start treating the control as noise instead of protection.

Practical implication: Track prompt volume, exception use, and approval behaviour together so you can spot when friction is undermining assurance.

What starter policies do in an RBA rollout

Starter policies translate risk logic into a simple ruleset that administrators can review and tune. The article’s pattern is straightforward: known user plus managed device plus normal location can be allowed, while unmanaged devices, privileged actions, new devices, and legacy authentication should trigger step-up or block decisions. This matters because RBA only works when the first policy set is small enough to audit and consistent enough to explain. If the initial rules are too broad, teams recreate the same friction problem under a new label.

Practical implication: Begin with a small, auditable policy set and expand only after you can explain the outcomes to security and business stakeholders.

Threat narrative

Attacker objective: Obtain authenticated access by inducing users to approve malicious MFA prompts.

1. Attackers overwhelm legitimate users with repeated MFA push notifications, turning approval fatigue into a social engineering entry path. Users respond by approving prompts reflexively, especially when the requests appear routine or arrive in bursts.
2. Once a prompt is approved, the attacker gains authenticated access through the victim’s identity rather than through password theft alone. The abuse succeeds because the control relies on human response under pressure.
3. The impact is account compromise and a weakened authentication boundary, especially where privileged or high-value access is protected only by push-based MFA and exception-heavy policy.
4. The objective is to bypass authentication resistance and obtain durable access to corporate systems by exploiting user fatigue and approval habits.

Breaches seen in the wild

• Cisco Yanluowang breach 2022: A password synced to a personal Google account plus vishing and MFA fatigue opened Cisco's VPN; the attacker then abused machine accounts.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA fatigue is not a user-training problem first, it is a policy precision problem. When organisations challenge too often, they teach users to treat authentication as background noise. That is why the control degrades from assurance into interruption, especially in environments that rely on push approvals and ad hoc exemptions. The practitioner conclusion is that prompt quality matters as much as prompt strength.

Risk-based authentication is the operational form of livable Zero Trust. Zero Trust cannot survive at scale if every access request is treated as equally suspect, because that produces exceptions for the very people and applications that matter most. RBA restores credibility by reserving friction for genuinely risky sessions and letting routine access move without weakening the boundary. The implication is that Zero Trust success depends on selective challenge, not universal challenge.

Authentication metrics are governance metrics, not just help-desk metrics. Coverage, prompt rate, step-up yield, and legacy authentication usage tell you whether the identity programme is actually enforcing the intended control model. Without those measures, teams cannot distinguish a well-tuned policy from a noisy one that users simply tolerate. The practitioner conclusion is that measurement is the only way to know whether authentication is being governed or merely operated.

Exemptions for VIPs and admins create an identity blast radius. The more frequently organisations carve out temporary exceptions, the more they shift risk away from the policy and into human judgment. That assumption was designed for stable access patterns, but it fails when access decisions are continuous and context-dependent. The implication is that governance teams must treat exemptions as a structural control gap, not a convenience feature.

Prompt fatigue exposes the limits of static authentication thinking. A control that cannot adapt to device trust, session context, or resource sensitivity becomes either too weak or too annoying to be effective. That is why the most useful RBA programmes unify security and experience around measurable decision quality. The practitioner conclusion is that authentication should be tuned as a control loop, not administered as a fixed gate.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust for AI Agents

What this signals

Selective challenge is the real Zero Trust test: organisations that cannot tune authentication will eventually compensate with exceptions, and exceptions are where assurance breaks down. Risk-based authentication matters because it gives teams a way to preserve friction where it is useful and remove it where it becomes noise.

Prompt rate, step-up yield, and legacy authentication usage are better programme signals than user satisfaction alone, because they show whether identity controls are getting more precise or merely more tolerated.

Teams that still rely on static MFA policies should treat prompt fatigue as an operational warning. The control boundary has to move from universal challenge to context-aware decisioning if authentication is going to support both security and usability.

For practitioners

• Define the first RBA decision tree Start with a small set of allow, step-up, and deny rules tied to user context, device posture, location, and resource sensitivity.
• Remove blanket exemptions for privileged users Replace standing VIP and admin carve-outs with context-based policy so privileged access is no easier to misuse than routine access.
• Measure prompt rate and challenge yield weekly Track prompts per user, step-up success, false positives, and false negatives so policy tuning is based on evidence instead of anecdotes.
• Block legacy authentication paths for high-risk accounts Prioritise modern authentication and remove basic protocols that bypass the strongest RBA signals, especially for admins and sensitive applications.
• Use device binding for high-risk access Tie the authentication flow to managed hardware so challenge traffic cannot be redirected to an unauthorised device.

Key takeaways

• Frequent MFA prompts weaken assurance when users start approving them reflexively or asking for exemptions.
• Risk-based authentication improves control quality by concentrating friction on risky sessions instead of routine ones.
• A measurable authentication programme should show lower prompt volume, better step-up precision, and less reliance on legacy access paths.

Key terms

• Risk-Based Authentication: An access model that changes verification requirements based on the estimated risk of the request. It combines identity assurance, device posture, application sensitivity, and contextual signals to decide whether to allow, block, or step up verification before access is granted.
• MFA Fatigue: MFA fatigue is the behavioural pressure created when repeated login prompts make a person more likely to approve access without checking carefully. It is a control failure in the authentication experience, and it becomes dangerous when the approved session carries broad privilege or long-lived access.
• Prompt Rate: The number of authentication challenges a user receives over a defined period. It is a useful operational measure because excessive prompt volume often signals poor policy precision, rising friction, or a control design that users will eventually learn to ignore.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.

What's in the full article

Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:

• The full starter-policy examples for allow, step-up, and deny decisions across different access contexts.
• The KPI definitions and rollout thresholds used to judge whether RBA is actually reducing fatigue.
• The article’s practical guidance on prompt-rate, challenge-yield, and legacy-auth measurement.
• The FAQ examples that map RBA to common authentication and device-binding questions.

👉 The full Unosecur post covers starter policies, KPI thresholds, and prompt-tuning examples.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.