Less ping, more proof: Risk-based authentication for reducing MFA fatigue

Most Zero Trust programs stall when users drown in prompts and teams add “temporary” exemptions for VIPs, admins, or legacy apps. Risk-based authentication restores momentum by challenging only when risk is high and letting low-risk sessions flow, without weakening security.

Let’s understand the need to measure authentication, how RBA reduces MFA fatigue, what to roll out first, and the specific KPIs that prove you’ve improved both security and experience.

TL;DR

• Risk-based authentication is how Zero Trust becomes livable. 
• By challenging smartly instead of constantly, you cut fatigue, remove risky exemptions, and strengthen security where it matters most. 
• Stand up the starter policies, wire the metrics into your dashboard, and review them weekly.
• The prompts will drop, and your assurance will rise.

Why you need metrics for authentication

Authentication changes can feel subjective until you wire them into a dashboard. 

Metrics convert “it feels better” into a shared language for security, IT, and the business. They show coverage (who is actually protected), reduction (how much risky behavior is shrinking), speed (how fast you detect and fix identity incidents), and automation (how often playbooks close issues without humans). Without numbers, you can’t tune prompts or prove that security has become easier to use. 

If a control can’t be measured, it can’t be tuned; if it can’t be tuned, it will drift. RBA is especially sensitive to feedback loops, so invest in numbers before you expand policies.

What is MFA fatigue?

MFA fatigue is user resistance caused by frequent or poorly timed challenges, especially push prompts. It happens when legitimate users are challenged so often, or at such poor times, that they resist, look for workarounds, or worse, approve malicious prompts. Classic causes include blanket push notifications, legacy protocols that force extra checks, and exemptions for VIPs and admins that create new gaps. Over-prompting leads to ticket spikes, workarounds, and risky exemptions. In extreme cases, users approve malicious prompts (“push-bombing”). 

The goal isn’t to slash prompts indiscriminately; it’s to remove unnecessary challenges while making high-risk moments demand stronger, phishing-resistant proof.

What is risk-based authentication?

Risk-based authentication evaluates each request in real time and sets the action: allow, step-up, or deny. It evaluates a request using the signals you already collect: the identity’s role and recent behavior, the device’s health and management status, the network and location, and the sensitivity of the resource. 

A routine request from a managed device in a known location may pass silently. A privileged action from a new device on a risky network may require a FIDO2 step-up or be blocked outright. Think of RBA as a policy brain that swaps “always prompt” for “prompt when it matters” and swaps weak step-ups for stronger ones when the risk is real.

Common signals

• Identity and role risk (privileged, contractor, service account)
• Device posture (managed/unmanaged, health, OS version)
• Network context (new IP, TOR/VPN, geo-velocity, impossible travel)
• Session/behavior (unusual time, transaction sensitivity, anomalies)
• Resource criticality (prod admin console vs wiki)

How does RBA reduce prompts and increase security?

By letting low-risk flows proceed, RBA cuts the background hum of approval requests that trains users to click “yes.” 

At the same time, it concentrates friction where it has the highest payoff: sensitive transactions and suspicious context. That means fewer exemptions for executives and admins, because their day-to-day work can be both low-prompt and high-assurance when it rides on passwordless factors and context checks. 
Every decision (allow, challenge, or deny) also generates telemetry you can analyze weekly to keep false positives and false negatives trending down. The change should be reflected in your starter policies. 

What are starter policies in RBA?

Starter policies are the first, minimal set of risk-based authentication rules you launch with: easy to explain, audit, and tune. They replace blanket MFA with context-aware decisions so you cut friction without losing security. You can use the following structure to create your starter policies.

• Known user + managed device + normal location → Allow.
• Known user + unmanaged device → Step-up with FIDO2; limit to low-risk apps.
• Privileged action (prod change, access review approval) → Step-up with FIDO2 + re-auth.
• New device + high-risk IP or geo-velocity → Deny and require device registration.
• Legacy protocol or basic auth → Block; require modern auth migration.

What are the metrics that measure the effectiveness of RBA in reducing MFA fatigue? 

1) MFA coverage (%): overall and admins:This tracks how much of the organization is actually protected. It reduces credential-based risk and sets the floor for RBA to work. 

What it tracks: How much of your org is protected.
Why: Broad coverage reduces credential risk.
KPI: Admins 100%, workforce ≥ 95%.

2) Passwordless adoption (%): interactive logins:This measures the share of sign-ins using phishing-resistant methods such as FIDO2 or passkeys. Higher adoption lowers prompt fatigue and raises assurance. 

What it tracks: Share of phishing-resistant auth.
Why: Lower fatigue, higher assurance.
KPI: Admins ≥ 60% in 90 days; workforce ≥ 30% and rising.

3) Prompt rate per user (per week): This is your friction gauge: how often users are being asked to approve something. As RBA matures, this number should fall without security incidents rising. 

What it tracks: User friction.
Why: Direct proxy for fatigue.
KPI: ≤ 3 prompts/user/week (admins may be slightly higher during rollout).

4) Step-up challenge rate (%) and yield:The challenge rate tells you how frequently the system asks for stronger proof; yield tells you whether those challenges align with risky sessions. Over time you want stable or fewer challenges, with a growing share attached to truly risky conditions.

What it tracks: Fraction of sessions challenged and how often step-ups prevent risk.
Why: Measure precision; avoid blanket prompting.
KPI: Challenge rate stable or lower over time; yield (risky sessions correctly challenged) ↑.

5) High-risk block rate (%): This captures the percentage of requests the system denies outright because the risk is clear. A non-zero, steady rate indicates the policy is actually stopping bad access. Sudden spikes deserve investigation rather than celebration.

What it tracks: Sessions denied due to clear risk (e.g., impossible travel + unmanaged device).
Why: Ensures policies actually stop bad access.
KPI: Non-zero and stable; investigate spikes.

6) Legacy auth usage (%): If basic or legacy protocols remain, they often bypass your best controls. Track their share of logins and drive it down to zero for admins and below one percent for the organization, trending toward zero as systems are modernized.

What it tracks: Basic/legacy protocols usage.
Why: bypasses RBA and modern controls.
KPI: Admins 0%; org < 1%, trending to 0.

7) Auth help-desk tickets per 100 users:Security that is easier to use should also be cheaper to support. Watch this number fall after the second week of your pilot; if it rises, revisit your policies or communication plan.

What it tracks: Operational burden from auth friction.
Why: Validates user experience gains.
KPI: Downward trend after week 2 of RBA.

8) False-positive / false-negative ratio (weekly review): A weekly look at mistaken challenges versus missed risks keeps you honest. Both should decline as you iterate; documenting each policy change and its effect prevents you from chasing noise.

What it tracks: Over-challenging vs missed risk.
Why: Keeps tuning honest.
KPI: FP and FN are both trending down; document policy changes.

‍