MFA fatigue is not a user education failure. It is an architectural failure. When every login, every sensitive operation, and every application access triggers a push notification, users face a choice dozens of times a day between security friction and productivity. Most choose productivity — not because they are careless, but because the volume of prompts has made individual approval decisions meaningless. Intelligent step-up authentication reframes this problem by restricting MFA challenges to moments where the risk context actually warrants them, eliminating the ambient prompt noise that produces the fatigue without compromising the security that MFA provides when it matters.
The MFA Fatigue Attack: How It Works and Why It Succeeds
MFA fatigue attacks — also called MFA push bombing or MFA spamming — exploit a simple behavioural pattern. An attacker obtains a user's primary credentials through phishing, credential stuffing, or purchase from a breach database. They then repeatedly attempt authentication, each attempt triggering a legitimate MFA push notification to the user's enrolled device. The notifications continue — one every few seconds or minutes — until the user approves one, either because they believe one of their own actions triggered it, because they want to stop the notifications, or because after ten or twenty prompts their attention lapses.
The attack has claimed notable victims. Uber's 2022 breach involved an attacker who, after obtaining an employee's credentials, bombarded them with MFA push requests for over an hour before the employee approved one, granting full access to Uber's internal systems. Cisco's 2022 breach followed a similar pattern — an employee's personal Google account was compromised, credentials reused from it against a Cisco VPN, and MFA fatigue used to gain entry despite modern MFA being in place. In both cases, MFA was correctly deployed and technically functioning — the failure was human, produced by architectural decisions that made MFA fatigue possible.
The architectural decisions that create fatigue are: using push-based MFA (where approval is a single tap) rather than phishing-resistant MFA (FIDO2/passkeys, where approval requires device presence and intentional action), and prompting for MFA on every session regardless of risk context. Both increase the volume and reduce the deliberateness of individual approval events. Intelligent step-up authentication addresses the second problem; FIDO2 adoption addresses the first. Together they eliminate the attack surface.
What Step-Up Authentication Is
Step-up authentication is the practice of requiring additional authentication factors at specific moments during a session — when the risk context changes or when a high-sensitivity operation is requested — rather than at fixed intervals or on every session start. The user authenticates initially with whatever factor their risk profile warrants (which may be passwordless for a low-risk session on a trusted device), then encounters a step-up challenge only when they attempt something that the policy engine has flagged as requiring elevated assurance.
The critical distinction from standard MFA is the trigger. Standard MFA triggers on session initiation, and sometimes on periodic re-authentication intervals. Step-up authentication triggers on risk signals and transaction sensitivity — meaning the challenge occurs because something specific warrants it, not as a routine event. This distinction changes the user's relationship with the prompt: a step-up challenge that occurs when you attempt to transfer a large sum, change your account email, or access an admin console carries obvious contextual meaning. A push notification that arrives because you started a session carries no such meaning and trains the approval reflex that fatigue attacks exploit.
The security value of an MFA challenge is proportional to the deliberateness of the user's response. A prompt that arrives with clear context — "you are attempting to change your password" — produces a considered decision. A prompt that arrives without context — the fifteenth push notification of the day — produces an automatic response. Intelligent step-up authentication is designed to make every MFA challenge meaningful, which makes every approval deliberate, which makes fatigue attacks structurally much harder to execute.
Risk Signals That Trigger Step-Up
An effective step-up authentication policy is built around a defined set of risk signals that, when present, shift the trust level of a session and trigger an additional verification requirement. These signals fall into three categories: contextual anomalies, transaction sensitivity, and threat intelligence.
Contextual anomalies are deviations from the user's established access patterns. A new device — one not previously enrolled in your device trust framework — warrants step-up because you cannot confirm the device's security posture. An unusual access location — a country the user has never accessed from, or an IP range associated with anonymisation infrastructure — warrants step-up because the source's trustworthiness cannot be confirmed. An impossible travel event — authentication from London followed within the hour by authentication from Singapore — warrants step-up or session termination because the two events cannot be explained by normal user behaviour.
Transaction sensitivity is a policy-level trigger independent of risk anomalies. Certain operations are inherently high-value enough to require elevated assurance regardless of the current risk score: changing the account email or phone number, resetting a password, initiating a wire transfer above a defined threshold, accessing administrative consoles, modifying MFA enrolment, or downloading sensitive data in bulk. These operations warrant step-up even when everything about the session looks normal, because the potential impact of an attacker reaching them with a hijacked session justifies the friction cost of verification.
Threat intelligence triggers are external signals that elevate the risk of a specific identity or session: the account's credentials appearing in a new breach database, the source IP appearing in a current threat intelligence feed, or an identity threat detection platform flagging the account for anomalous behaviour patterns consistent with credential compromise. These signals can be integrated in real time through your identity provider's risk engine — Okta ThreatInsight, Microsoft Entra ID Protection, and Cisco Duo's threat intelligence integrations all provide mechanisms for external signal ingestion that feeds step-up policy decisions.
Implementation Architecture: Where Step-Up Lives in the Stack
Step-up authentication is implemented at the identity provider and policy engine layer, not at the application layer. Applications signal to the identity provider that they are requesting elevated assurance — typically by requesting a specific Authentication Context Class Reference (ACR) value in the authentication request — and the identity provider determines whether the current session satisfies that assurance level or whether a step-up challenge is required.
Okta's authentication policies support step-up natively: applications can request specific assurance levels for sensitive operations, and Okta evaluates the current session's assurance against the requested level, triggering step-up only when there is a gap. Microsoft Entra ID implements step-up through Conditional Access — policies that enforce specific authentication strengths for specific resources or operations, with re-authentication requirements when the session's current strength is below the policy threshold. Ping Identity's DaVinci orchestration platform allows step-up policies to be built as visual orchestration flows, with risk signals from multiple sources feeding into branching authentication journeys.
ForgeRock (now part of Ping Identity) offers one of the most flexible step-up implementations through its Intelligent Access Trees — scripted authentication journeys where any node in the journey can be a step-up trigger, allowing arbitrarily complex risk logic to be expressed without custom application code. For organisations with complex, multi-application environments where different sensitivity levels apply to different operations across many systems, this orchestration flexibility is practically significant.
The application integration model for step-up depends on the protocol. For OIDC/OAuth applications, the application requests elevated assurance through the acr_values parameter in the authorisation request and verifies the returned acr claim in the ID token. For SAML applications, step-up is requested through the AuthnContextClassRef element. Legacy applications that cannot express assurance requirements natively can have step-up enforced at the network access or API gateway layer — the gateway enforces assurance level requirements before proxying the request to the application, without the application needing to participate in the step-up protocol.
High-Risk Transaction Patterns: What Always Warrants Step-Up
Independent of risk scoring and session anomalies, certain transaction patterns should always trigger step-up authentication as a policy baseline. Identity operations — changing email, phone, or authentication factors enrolled on an account — are the highest priority: an attacker who can perform these operations without step-up can lock out the legitimate user and take permanent control of the account. Require step-up for any modification to account recovery information, enrolled MFA methods, or trusted devices, without exception.
Financial operations above defined thresholds should require step-up that is proportionate to the amount and transaction type. A step-up policy for financial operations typically defines tiers: transactions below a threshold use the session's existing assurance level; transactions above it require a step-up challenge; transactions above a higher threshold require phishing-resistant authentication (FIDO2) regardless of how the session was initiated. This tiered approach limits friction for routine transactions while providing strong assurance on those with significant financial exposure.
Administrative operations — access to admin consoles, bulk data exports, permission changes, system configuration modifications — should require step-up to a phishing-resistant factor for all users with administrative access. The blast radius of a compromised administrative session justifies the friction, and the frequency of administrative operations is typically low enough that the challenge cadence does not produce fatigue. Requiring FIDO2 for admin console access is one of the most impactful single security improvements an enterprise can make, and step-up enforcement at the policy layer is the mechanism that makes it consistent.
Measuring Success: From Prompt Fatigue to Signal Quality
The metrics that matter for a step-up authentication programme are not the metrics that matter for standard MFA deployments. Standard MFA success is measured by enrolment rate and challenge completion rate. Step-up success is measured by prompt precision — the ratio of challenged sessions that exhibited genuine risk signals to total challenges issued — and by the approval rate for step-up challenges, which should be high (because challenges occur when there is a reason) compared with push-based MFA in fatigue-prone environments.
Track three metrics in production: total step-up challenges issued per week (should decline over time as policy calibration reduces unnecessary challenges), step-up approval rate (approvals as a percentage of challenges — a declining approval rate suggests fatigue is building, indicating challenge volume is too high or challenge context is unclear), and step-up bypass rate (sessions that should have triggered step-up but did not, identified through post-incident review). The third metric requires deliberate monitoring — policy gaps that allow high-risk operations to proceed without step-up are invisible until an incident exposes them.
The long-term measure of programme success is the change in account takeover incidents attributed to credential compromise. Intelligent step-up authentication does not prevent credential theft — it prevents credential theft from translating into account compromise for the specific operations that generate business impact. If account takeover incidents cluster around operations that are not covered by your step-up policy, those operations need to be added. The programme is never complete; it evolves as the threat landscape and the business's risk profile evolve alongside it.