What are the signs that push-based authentication is becoming unsafe in an organisation?

Warning signs include repeated login prompts, unusual geolocation alerts, unexplained approval activity, and users reporting prompt fatigue. If admins cannot quickly distinguish legitimate prompts from malicious ones, the control is drifting toward abuse. Security teams should watch for account lockouts, credential exposure after a suspicious approval, and patterns that suggest users are being conditioned to accept requests.

When push-based authentication stops being a reassuring signal

Push-based authentication becomes unsafe when the prompt itself stops being a meaningful test of user intent. At that point, approvals can be manufactured through fatigue, confusion, or social engineering rather than genuine verification. The operational question is whether the organisation can still trust a push as evidence of the right person making the right decision.

Repeated prompts are an early warning because they train users to click through friction. If approval events no longer correlate with a known login attempt, device change, or expected access path, the signal quality is deteriorating. That matters even before a formal compromise, because the control is already shifting from verification to habituation.

Security teams should treat unexplained approval activity as a control failure, not just noisy telemetry. A safe push flow should be intelligible to the user, bounded by context, and distinguishable from an attacker’s abuse of the same channel.

What the warning signs usually look like

The most common signs are behavioural and operational rather than purely technical. MFA fatigue attacks often show up as repeated push requests, users saying they are being bothered at odd times, or approvals arriving without a corresponding legitimate action. When those patterns become routine, the control is no longer functioning as a meaningful second factor.

Other signals include unusual geolocation alerts, approval attempts from unfamiliar devices, and users reporting that prompts arrive when they are not actively signing in. If help desk staff begin to see account lockouts after a suspicious approval, or users say they approved something they do not remember, the organisation should assume the trust boundary is weakening.

For organisations using modern phishing-resistant options, the gap becomes clearer because the safer path should not depend on user habit. NIST SP 800-63 Digital Identity Guidelines reinforces the value of authenticator strength and phishing-resistant authentication, which is exactly what push-only flows lack when they are easy to prompt-spam.

Why the control becomes dangerous at scale

Push fatigue is dangerous because it turns a low-friction usability feature into an attacker’s persistence mechanism. A malicious actor does not need to defeat the authenticator if they can repeatedly interrupt the target until one approval slips through. Once that happens, downstream access can expand quickly, especially where the approved session opens internal tools, email, or credential stores.

That risk is amplified when the push is the default approval path for many users and the organisation has weak context signals around location, device, and session history. The control can appear healthy in dashboards while still being easy to socially engineer in practice. In other words, volume alone is not evidence of safety; it can be evidence that users are being conditioned.

Organisations that rely on push prompts should also watch for signs that the approval channel is being reused as a general acceptance mechanism for too many decisions. Once users expect prompts as routine background noise, the attacker’s job becomes substantially easier.

Risk and Threat Considerations

Push-based authentication becomes a threat surface when an attacker can generate enough prompts to create confusion, urgency, or fatigue. The risk is not only account compromise, but also silent normalisation of suspicious approvals that makes detection and user reporting less reliable.

Failure mechanism: The attacker repeatedly triggers prompts, times them to exploit distraction, or pairs them with social engineering so the user approves a request without verifying the context.

Impact: A single accepted prompt can open a trusted session, expose sensitive systems, or enable follow-on activity such as mailbox access, credential theft, or lateral movement.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Phishing-resistant authentication is central to judging when push prompts stop being trustworthy.
Recommendation — Prefer phishing-resistant authenticators for higher-risk access instead of relying on push approvals.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	User authentication quality and MFA failure modes directly determine when push auth becomes unsafe.
	IA-5 — Authenticator Management	Push notifications depend on authenticators and their lifecycle, rotation, and abuse resistance.
Recommendation — Verify that organizational-user authentication resists prompt fatigue and social-engineering abuse. Review authenticator handling and remove approval paths that are easy to spam or reuse.

Practitioner Guidance

What to verify: Treat push authentication as unsafe when approvals are not tied to an expected login event, known device, and plausible user action. If the organisation cannot explain why a prompt occurred, assume the signal has degraded and investigate the surrounding identity session rather than the prompt in isolation.

Decision rule: If users are reporting prompt fatigue, unexplained approvals, or repeated lockouts, move away from push-only approval as the primary factor for higher-risk access. The practical threshold is not whether the push still works, but whether it still provides a clear, contextual, and user-verifiable challenge.

Practitioner takeaway: The control is unsafe once it can be exploited as a repetition game. The key judgement is whether the prompt still proves intent, or whether it has become just another message users are trained to dismiss.