MFA Push Fatigue on the VPN
Over 48 hours, the helpdesk logs 60 'I keep getting MFA prompts' tickets from users across departments. The IdP shows a spike in push approvals from unfamiliar ASNs, mostly between 01:00 and 04:00 local. Three users approved a push 'by accident.' One of those three, a finance manager, then had her VPN session used to access the ERP reporting module from an IP geolocated to another country. The IdP currently uses push-only MFA with no number matching, and the VPN allows any authenticated user to reach the ERP subnet. The finance manager is traveling and unreachable for 6 hours.
1. What is happening, and what are your immediate containment actions in priority order?
Read the worked answer
Diagnosis: MFA push-fatigue (MFA bombing) leading to at least one successful account takeover.
Evidence chain: 60 'unexpected prompt' tickets + off-hours pushes from new ASNs + three accidental approvals + one approved session now active from a foreign IP against ERP = credential compromise (password already known to attacker) with MFA bypassed by user fatigue.
Containment, in order:
- Kill the active session and reset the finance manager's credentials - revoke all refresh tokens/sessions at the IdP, force password reset. Do not wait for her; the session is live now. Use break-glass admin process and document it.
- Treat the other two accidental approvers as compromised - revoke sessions and reset, even though no misuse is visible yet.
- Block the offending ASNs/IPs at the IdP and VPN as a stopgap (not a fix - attackers rotate).
- Pull ERP access logs for the finance manager's account: what reports were viewed/exported, any config changes, any data exfil. Preserve logs before retention rolls.
- Notify finance/ERP owner - this is a potential data-access incident, not just an auth event; the data owner decides on disclosure obligations.
- Check for persistence: new MFA devices enrolled, mailbox rules, OAuth app consents, new VPN profiles.
Do not just reset passwords and call it done - the live session is the active threat.
2. What durable fixes do you make, and how do you sequence them given that number-matching MFA requires a client update and some users are on old phones?
Read the worked answer
Durable fixes, sequenced by risk reduction per unit effort:
- Switch to number-matching (or phishing-resistant) MFA - highest value. Number matching kills blind push approval. Sequence: enable number matching tenant-wide first (works on existing authenticator app versions in most cases), then pilot FIDO2/passkeys for high-risk roles (finance, admins) where the old-phone constraint is least acceptable. For users on unsupported phones, issue a hardware key or TOTP as fallback - do not leave push-only as the fallback.
- Conditional access / risk-based policy. Block or step-up legacy auth, impossible-travel, and unfamiliar-ASN sign-ins; require compliant device for VPN. This shrinks the window even if a push is approved.
- VPN least privilege. The finance manager reaching ERP from anywhere is the real amplifier. Restrict ERP subnet access to a defined group and require device posture; segment so VPN ≠ flat access to finance systems.
- Rate-limit / alert on push volume per user at the IdP - 10 pushes in 5 minutes should auto-lock and alert, not keep ringing.
- User comms: tell staff the correct behavior is to deny and report, never approve an unexpected prompt; the 60 tickets show they mostly did the right thing.
Sequencing: number matching + CA risk policies this week; FIDO2 for privileged/finance in 30–60 days; VPN least privilege in the next change window. Track old-phone users explicitly so the fallback isn't a silent hole.