Why do sprayed passwords and MFA fatigue still work against cloud tenants?

They work because many environments still allow repeated authentication attempts against internet-facing identities and rely on human-paced approval flows. Attackers operate faster than review cycles and can exploit legacy paths, weak recovery, or push-based MFA habits. That makes tenant hardening and phishing-resistant factors essential, especially for privileged accounts.

Why Spray and Push Abuse Still Succeeds in Cloud Tenants

Cloud tenants remain attractive because the attack surface is exposed to the internet, the authentication pipeline is often shared across many identities, and defenders still tolerate control paths that reward volume rather than intent. Password spraying works when tenants allow enough failed attempts, weak recovery paths, or inconsistent lockout logic. mfa fatigue works when push approvals are treated as a normal user task instead of a security decision.

The real issue is not that cloud providers lack strong controls in theory. It is that many organisations deploy those controls unevenly, leave legacy authentication enabled, or fail to align policy with the speed and persistence of real attackers. A tenant can be secure on paper and still remain reachable through one weak account, one old protocol, or one approval habit that users have been trained to click through.

That gap is why identity hardening matters as much as perimeter hardening in cloud environments, and why phishing-resistant factors are now the safer default for privileged access. NIST Cybersecurity Framework 2.0 frames this as an ongoing identity and access governance problem, not a one-time configuration exercise. In practice, many security teams discover spray success only after repeated low-and-slow probing has already found the least protected tenant path.

How the Attack Pattern Works in Practice

Password spraying succeeds because attackers spread login attempts across many accounts and stay under common detection thresholds. Instead of trying one password many times, they try one or a few passwords against many users. That avoids account lockouts in poorly tuned environments and can still hit legacy identities, stale accounts, or accounts with weaker password hygiene. When tenants support basic authentication, weak recovery workflows, or externally reachable login endpoints, the odds improve further.

MFA fatigue, sometimes called push bombing, works differently but targets the same weakness: human response under pressure. The attacker first obtains a valid username and password, then repeatedly triggers push prompts until a user approves one, dismisses one by mistake, or contacts help desk staff who bypass friction to restore access. If approval prompts do not clearly show context, device, location, or reason, users are left to decide quickly with incomplete information. That is exactly where social engineering thrives.

Current guidance suggests that the most reliable reduction comes from narrowing what can be attacked, not just alerting on it faster. Disable legacy authentication paths where possible, require strong and phishing-resistant MFA for privileged roles, and make risky sign-in responses dependent on real-time context rather than static trust alone. Account protection also needs event correlation, because a single alert rarely tells the full story when the attack is distributed across time and identities.

Tighten sign-in policies around location, device state, and impossible travel indicators where those signals are meaningful.
Remove or isolate legacy protocols that bypass modern MFA enforcement.
Prefer authentication methods that bind the factor to the session or device, not just to the user.
Review help desk and recovery workflows, since attackers often pivot there after defeating the login flow.

NHIMG research on non-human identity maturity shows the broader pattern: many organisations still report that their access practices lag behind their confidence, which is a useful warning sign for tenant authentication too. The controls tend to break down when a cloud tenant mixes modern and legacy sign-in paths, because enforcement becomes inconsistent and attackers only need the weakest reachable path.

Where the Usual Defences Break Down

Tighter authentication control often increases user friction and operational overhead, so organisations have to balance usability against abuse resistance. That tradeoff becomes especially visible for high-privilege users, contractors, and hybrid workforces, where a single bad exception can weaken the whole tenant.

One common edge case is recovery and exception handling. Even when the primary sign-in path is hardened, password reset, device re-enrolment, and support-assisted unlock flows can remain easier to abuse than the main login screen. Another is push-based MFA that is technically enabled but still socially weak because users have not been trained to treat unsolicited prompts as a security incident.

There is no universal standard for every tenant configuration, but best practice is evolving toward phishing-resistant authentication for privileged access and tighter policy enforcement for all externally exposed identities. Microsoft Midnight Blizzard breach is a relevant example of why persistent password-based access and weakly defended identity paths remain attractive even in mature environments. Microsoft Midnight Blizzard breach illustrates how identity attack paths can remain viable when controls are not uniformly enforced across the tenant.

In practice, the hardest failures are rarely in the primary login mechanism itself; they are in the exception paths, the recovery paths, and the human habits that attackers can keep pressuring until one approval slips through.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA	Cloud tenant spray and MFA abuse are identity assurance failures.
Recommendation: Identity assurance should resist repeated guessing and approval abuse, not just detect it.
NIST Zero Trust (SP 800-207)	4	Tenant abuse is reduced when access decisions are continuously validated.
Recommendation: Access should be context-driven and revalidated rather than trusted after initial login.
OWASP Non-Human Identity Top 10	NHI-01	Tenant accounts and service identities need clear ownership and lifecycle control.
Recommendation: Unowned or stale identities become the easiest spray and recovery targets.
NIST SP 800-63	5.2	MFA fatigue exploits weak enrollment, recovery, and authenticator handling.
Recommendation: Authenticator lifecycle and phishing resistance should limit approval abuse and reset bypasses.

Risk and Threat Considerations

Cloud tenants are vulnerable to distributed credential-guessing and push-approval abuse because authentication remains internet-facing and many environments still allow fallback paths or tolerant retry behaviour. The risk is not just account compromise but the gradual normalisation of weak access paths that attackers can probe at scale.

Failure mechanism: Spray attacks exploit low-and-slow guessing across many accounts to stay under lockout and alert thresholds, while MFA fatigue turns repeated push prompts into a social engineering channel. When legacy auth, recovery workflows, or help desk exceptions remain reachable, the attacker can pivot from failed logins to easier bypass paths.

Impact: A single successful compromise can expose tenant data, mailbox content, cloud consoles, or privileged administration paths. The longer the weak paths remain in place, the more likely attackers are to obtain durable access without triggering a clear, immediate containment event.

Practitioner Guidance

Teams often overestimate MFA because it exists, not because it is hard to coerce. The real failure is usually inconsistent enforcement across tenant entry points and recovery paths, plus user training that treats approval prompts as routine instead of suspicious.

Disable legacy and bypassable authentication methods for all internet-facing tenant identities, then verify the setting at the directory and application layers.
Move privileged accounts to phishing-resistant MFA and separate their sign-in policy from standard user populations.
Set alerting and response playbooks for repeated push prompts, atypical geolocation, and low-and-slow login spraying across many accounts.
Audit password reset, device re-enrolment, and help desk unlock workflows for shortcuts that can be used to bypass the primary MFA policy.
Review tenant exceptions monthly and require explicit owner approval for any account that can still authenticate with weaker methods.