Push notifications that ask "approve this login?" look like security. In practice they often become a habit users clear without reading. That habit has a name, MFA fatigue, and treating it as an acceptable cost of doing business is how account takeovers get past controls that looked fine in a design review.
I see this most clearly during auth migrations. Teams move off a legacy IdP, tighten password rules, turn on second factors for everyone, and then declare the project done. The dashboard shows high MFA enrollment. Support tickets about password resets drop. Nobody asks whether the second factor still requires a deliberate decision from a human who is awake and paying attention.
What fatigue actually looks like
Fatigue is not a user being careless in the abstract. It is a predictable response to a signal that fires too often, for reasons the user cannot judge, at moments when they are trying to do something else.
A contractor gets three push prompts in ten minutes because a mobile client, a desktop client, and a background refresh each trigger a new challenge. A salesperson gets prompts while driving. An engineer gets prompts while a CI job is retrying a token exchange that was never meant to look like an interactive login. After a few weeks of that pattern, the approve button becomes muscle memory. The prompt no longer carries information. It carries interruption.
Attackers know this. MFA bombing (sending a stream of prompts until someone accepts) works because the prompt design already trained people to clear interruptions. Number matching and similar confirmations help, but they only help if the challenge is rare enough that the number is read as a check, not as noise. If your users see twenty challenges a day, the matching step becomes another ritual they perform without thinking.
The migration angle matters because fatigue often arrives as a side effect of "more secure by default." You enable MFA everywhere. You keep password login as a fallback. You leave every client path that could request a session able to trigger a challenge. Enrollment looks complete. Risk scoring looks better on paper. The human in the loop is already exhausted.
Most of that fatigue is not caused by a single bad product choice. It is caused by stacking reasonable choices without a budget for how many times a person can be asked to decide.
Interactive login and silent token refresh get treated the same way. If your resource servers reject a slightly stale access token by forcing a full interactive challenge, every flaky network path becomes a push storm. Prefer silent refresh where the session is still valid, and reserve interactive MFA for moments that actually change trust: new device, new location that fails your risk rules, privilege elevation, recovery flows.
Multiple apps against the same IdP each implement their own "force reauth" shortcuts. Product A reauthenticates on every sensitive page. Product B reauthenticates on session resume. Product C reauthenticates because someone copied a middleware snippet from a blog post in 2019. From the IdP's point of view these are separate events. From the user's point of view they are the same button, again.
Fallback chains also leak fatigue. Password plus push, plus SMS if push fails, plus email OTP if SMS fails, sounds resilient. In practice each step is another interruption, and attackers will aim for the weakest link in the chain. If SMS remains available for everyone, you have not strengthened the strong path. You have preserved a soft path that support will keep recommending because it unblocks tickets quickly.
Legacy clients make this worse. Desktop apps that cannot do WebAuthn cleanly, mobile WebViews that break redirect state, and partner portals that still expect username and password will keep generating challenges even after your primary web app has moved to passkeys. During a migration, those legacy paths are often left "for later." Later is when fatigue becomes normal.
What to measure before you call MFA done
Enrollment rate is not the metric. Challenge volume per user per day is closer. So is the share of challenges that end in approval without a corresponding intentional login in your product analytics. If approvals spike while intentional sessions do not, people are clearing prompts, not authenticating.
Track how many challenges fire from non-interactive paths: token refresh, background sync, health checks that somehow call the authorize endpoint, and service accounts that were never meant to use interactive MFA. Those should be near zero. Every one of them trains fatigue.
Track support contacts that mention "keep getting asked to approve" or "approve by mistake." Those tickets are early warning. They usually appear weeks before a successful MFA bombing incident shows up in fraud review.
During migration cutovers, compare challenge rates between the old and new stacks for the same cohort. A temporary spike is normal. A permanent doubling that never comes back down means you moved friction without moving risk. That is the opposite of a successful cutover.
A calmer design for second factors
The goal is fewer decisions that matter more, not more decisions that matter less.
Prefer phishing-resistant factors for daily use when you can: passkeys and platform authenticators that bind to the origin. They remove the approve/deny interrupt pattern entirely for routine sign-in. Keep push or TOTP for recovery and for clients that cannot do WebAuthn yet, and treat those as temporary paths with an explicit retirement plan.
When you must use push, require number matching or an equivalent confirmation that cannot be satisfied by habit alone. Cap how many outstanding prompts a user can receive in a short window, and fail closed to a slower recovery flow instead of letting the prompt flood continue. Log and alert on prompt storms the same way you would alert on password spray.
Separate step-up from login. Opening the app should not require the same proof as exporting customer data or changing billing. If everything is "high risk," nothing is. Users learn that the hard challenge is ambient. Attackers learn that ambient challenges get approved.
Kill silent paths that look interactive. If a client cannot complete silent refresh, send it to a dedicated reauth screen with context ("confirm it is you to continue working in Acme"), not to a naked push with no product context. Context is part of the control. Without it, the prompt is just another notification.
Plan the migration so legacy clients stop generating noise. Either upgrade them, wrap them behind a broker that can use a better factor, or accept that those clients stay on a constrained trust tier until they can be retired. Leaving them on the main MFA path forever is how "temporary" fatigue becomes policy.
MFA is finished for a cohort when challenge volume is stable and low, when interactive challenges map to intentional high-trust moments, when fallbacks are narrow and monitored, and when support is not coaching people to approve faster. Enrollment alone never meant that.
If your current graph shows high MFA coverage and high prompt volume, you do not have a security strategy. You have a notification strategy with a security label. Fix the volume first. Then the second factor can do the job you thought it was already doing.