If your gut instinct is “more prompts = more security,” you’re not alone.
We recently worked with an organization that wanted to tighten session lifetimes and sign-in frequency policies to force frequent re-authentication and re-MFA across their environment, on top of bypass rules for “trusted networks.” The idea sounded sensible: tighten the screws, increase friction, reduce risk.
But there’s a growing body of evidence—and real-world breaches—that suggest the opposite:
Over-prompting MFA can actually reduce security by training users to approve anything.
Let’s unpack why, and what to consider when enforcing MFA in your environment.
MFA fatigue: when security becomes background noise
Attackers have increasingly shifted to MFA fatigue (aka push bombing) attacks. Once they’ve stolen a username and password, they spam the user with MFA prompts—sometimes hundreds of times—hoping the user will eventually hit “Approve” just to make it stop.
Microsoft has observed large volumes of MFA fatigue attacks, with a measurable percentage of users approving the first unsolicited prompt.
Now imagine you’re also training users to expect MFA prompts all the time:
- On a tight schedule (for example, every 30 days).
- On every network change.
- Across multiple devices and apps.
Over time, that prompt stops being a security checkpoint and becomes just another click.
The insight from that engagement was simple but powerful:
If you constantly ask users for MFA, they’ll approve prompts without thinking. If you rarely ask, an unexpected prompt becomes a signal that something might be wrong.
What Microsoft and NIST actually recommend
Both Microsoft and standards bodies like NIST have moved away from the “more friction is always better” mindset.
- Microsoft Entra ID’s default user sign-in frequency is a rolling 90-day window. The documentation explicitly warns that asking for credentials too often can backfire because users get used to entering them without scrutiny.
- NIST SP 800-63B no longer recommends arbitrary, periodic password changes and emphasizes that passwords should only be changed when there is evidence of compromise. Forced frequent changes tend to result in weaker, predictable patterns like “Password123!” or minor tweaks to old passwords.
The theme is clear:
Security should be risk-based and intelligence-driven, not calendar-driven.
The user experience trap: balancing security and productivity
In that organization’s case (and many others we see), there were two key stakeholders:
- An infrastructure leader focused on minimizing user disruption.
- A security leader focused on tightening controls, especially around MFA and session lifetime.
That tension exists in almost every environment. But if you try to “solve” security by piling on more prompts, you create:
- Security fatigue. Users stop reading what they’re approving.
- Support overhead. Help desk tickets about frequent sign-ins, lost devices, or confusing prompts.
- Shadow behavior. Users seek workarounds, like using personal devices or stale sessions, to avoid friction.
The result? You’ve added noise, not signal.
The hidden risk of “trusted networks”
Another pattern we see often:
“If it’s from the corporate network, skip MFA—it’s safe.”
On paper, whitelisting your office IPs sounds convenient. In practice, it can:
- Create a blind spot if an attacker gains a foothold on your internal network.
- Undermine the value of Conditional Access signals (device compliance, risk-based policies, etc.).
- Encourage a mindset that “inside = safe, outside = dangerous,” which simply doesn’t hold up in a hybrid, cloud-first world.
Microsoft’s guidance leans toward:
- Using modern authentication signals (like device compliance, risk levels, and sign-in risk) rather than just IP address.
- Minimizing exclusions and avoiding broad “bypass MFA on internal network” rules.
So what should you do? Principles for sane MFA enforcement
Here’s a more modern way to think about MFA:
1. Let the platform handle most of the decisions
Modern identity platforms like Microsoft Entra ID are designed to:
- Issue primary refresh tokens (PRT) to devices, allowing secure, seamless access without constant reauth.
- Evaluate risk signals and trigger MFA when something looks unusual (location, device, impossible travel, etc.).
Instead of layering manual 30-day timers on top, use:
- Adaptive session lifetime policies for high-risk apps or scenarios.
- Conditional Access to require MFA when risk is elevated, not every time a calendar reminder fires.
2. Use more secure MFA, not more frequent MFA
To defend against MFA fatigue:
- Turn on number matching or equivalent features in your authenticator app so users have to match a code, not just tap “Approve.”
- Add contextual information to prompts (location, app name, device) so users can tell if they initiated the sign-in.
- Avoid SMS and voice as your primary factor where possible; favor app-based or phishing-resistant methods.
3. Reserve frequent prompts for admins and crown-jewel apps
Our view (and Microsoft’s guidance backs this up) is:
- Admins and privileged roles: More frequent MFA, shorter sessions, and stricter controls are absolutely justified.
- Highly sensitive apps (e.g., financial systems, security consoles): Consider “every time” MFA or much shorter sign-in frequency.
- Typical knowledge workers: Rely more on risk-based policies and device trust, not arbitrary 30-day schedules.
4. Educate users about when to be suspicious
Technology alone doesn’t fix MFA fatigue. You also need user education:
- Teach users: “Only approve MFA when you just tried to sign in.”
- Show them how to check sign-in details (location, app, device) before hitting Approve.
- Make it easy for them to report suspicious prompts without fear of “bugging IT.”
MFA and passwords: the bigger picture
This MFA conversation mirrors what’s happened with passwords:
- We used to enforce complexity rules and 90-day expirations in the name of security.
- NIST and others now recognize that those controls often produced weaker passwords and frustrated users.
We’re having the same evolution with MFA:
- It’s not about how often you prompt.
- It’s about how smart your prompts are, and how well users understand them.
A better north star for MFA
Instead of “MFA every 30 days,” try using these questions to guide your design:
- Can we reduce prompts for low-risk, managed devices while maintaining strong assurance (PRT, Conditional Access)?
- Are we using fatigue-resistant methods like number matching and contextual prompts?
- Are admins and privileged accounts protected more aggressively than regular users?
- Have we eliminated broad “trusted network” bypass rules in favor of richer signals?
- Do users know what to do when they get an unexpected prompt?
If you can answer “yes” to those, you’re moving toward a model where:
- MFA is still mandatory and foundational.
- Users aren’t being nagged into complacency.
- Attacks that rely on fatigue and blind approvals become much harder to pull off.
Turning an “aha moment” into a roadmap
For that organization, the conversation about aggressive sign-in frequency and MFA prompts turned into a broader rethink of:
- How they treat internal vs. external sign-ins.
- How they configure session lifetime and sign-in frequency.
- How they communicate to users about MFA and suspicious activity.
The same shift can happen in your environment: away from “more prompts by default” and toward smarter, risk-based MFA that actually makes your organization safer.