Govern MFA Fatigue and Push Bombing Attacks

The 2:13 a.m. push notification that became a board question

At 2:13 a.m., a senior finance administrator receives a mobile notification: “Approve sign-in?” She is half asleep, assumes it is a timeout from a cloud finance platform, and taps approve.

By 2:19 a.m., the attacker is inside the identity provider. By 2:31 a.m., they are attempting access to a payroll export, a privileged cloud console, and a shared mailbox used for supplier payments. By 3:05 a.m., the SOC sees repeated MFA prompts, unusual geography, a successful approval, and a new session from an unmanaged device.

The morning conversation is familiar:

• “But we had MFA.”
• “Why did the user approve it?”
• “Did we log the MFA challenge details?”
• “Is this a personal data breach?”
• “Do we have 24-hour or 72-hour reporting obligations?”
• “Will our ISO 27001:2022 auditor treat this as a control failure?”
• “Does this affect NIS2, DORA, GDPR, customer contracts, or cyber insurance?”

This is the governance gap behind MFA fatigue and push bombing. Attackers are not breaking cryptography. They are exhausting human decision-making, exploiting weak authentication design, and looking for unmonitored exceptions. The control failure is rarely “MFA not enabled.” It is usually a chain of weak identity assurance, risky push approval design, missing number matching, unclear privileged access rules, insufficient authentication logging, poor alert triage, undertrained users, and no documented evidence that the organization reviewed and corrected the weakness.

For CISOs, compliance managers, auditors and business owners, MFA fatigue must be treated as an ISMS evidence problem, not only an identity provider setting. The answer combines ISO 27001:2022 risk treatment, ISO/IEC 27002:2022 controls, policy obligations, user awareness, incident response, supplier governance, and cross-framework mappings for NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT 2019.

MFA fatigue is an assurance failure, not a user problem

MFA fatigue, also called push bombing or prompt bombing, occurs when an attacker with a valid password repeatedly triggers MFA approval requests until the user accepts one. Sometimes the attacker adds social engineering, such as a fake helpdesk call, a message claiming “we are testing your account,” or a request to approve a login to stop notifications.

The operational danger is that organizations often treat all MFA as equivalent. It is not.

A simple “approve or deny” push notification is weaker than number matching, phishing-resistant FIDO2 security keys, certificate-based authentication, or conditional access that blocks impossible travel and unmanaged devices. MFA also fails when bypass exceptions are undocumented, service accounts are interactive, legacy protocols remain open, or high-risk access does not require stronger authentication.

In the Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec frames secure authentication in the Controls in Action phase, Step 19: Technological Controls I. The guidance is direct:

Authentication is the first and most critical line of defense between a threat actor and your systems, data, and services. If authentication is weak, everything else, encryption, monitoring, segmentation, can be bypassed.

The same Zenith Blueprint also addresses ISO/IEC 27002:2022 control 5.17 in Step 22:

If identity is the question, “Who are you?”, then authentication is the proof. Control 5.17 is where theory meets trust. It requires that authentication information be managed securely throughout its entire lifecycle, ensuring that the methods and credentials used to verify identity cannot themselves become the weakest link.

Those two statements explain why push bombing belongs in the risk register. Encryption does not help if the attacker becomes an approved user. Network segmentation helps less if privileged cloud access is approved through a fatigued prompt. Monitoring only works if authentication events are logged in enough detail and reviewed quickly.

A mature risk statement should be explicit:

This is where ISO 27001:2022 matters. The standard requires context, interested parties, leadership, risk assessment, treatment planning, operational control, monitoring, internal audit, management review and continual improvement. MFA fatigue touches all of them.

The ISO 27001:2022 control cluster auditors will test

ISO 27001:2022 provides the management system structure. ISO/IEC 27002:2022 provides implementation guidance for controls. For MFA fatigue and push bombing, auditors will usually focus on a cluster rather than a single control.

Clarysec’s Zenith Controls: The Cross-Compliance Guide maps ISO/IEC 27002:2022 control 8.5 Secure authentication to supporting controls such as 5.17 Authentication information, 8.2 Privileged access rights, 8.16 Monitoring activities, 5.24 Information security incident management planning and preparation, and 5.34 Privacy and protection of PII. This cross-link is important because a screenshot showing “MFA enabled” is not enough. Auditors want proof that authentication is designed, monitored, reviewed and improved based on risk.

A defensible evidence package should include:

1. Risk assessment identifying push bombing and social engineering of MFA prompts.
2. Authentication standard defining acceptable MFA methods by system criticality.
3. Privileged access policy requiring stronger authentication for admin and remote access.
4. Identity provider configuration export showing number matching, prompt limits, conditional access and blocked legacy authentication.
5. Logs showing successful and failed MFA events, denied prompts, impossible travel and device context.
6. Alert rules for repeated MFA prompts, repeated failures and unusual successful approval.
7. Incident response records for authentication-related alerts.
8. Awareness training content telling users not to approve unexpected prompts.
9. Access review records for privileged and high-impact systems.
10. Exception register with expiry dates, risk owner approvals and compensating controls.

Policy turns “do not approve unexpected prompts” into evidence

Many organizations tell users not to approve suspicious prompts. That advice is useful, but it is not enough for ISO 27001:2022 certification, NIS2 oversight, DORA resilience, GDPR accountability, customer due diligence, or cyber insurance.

The first policy anchor is P38 Secure Communications and Multi-Factor Authentication (MFA) Policy. It addresses the human side directly:

User Awareness: Users shall receive training to distinguish secure from insecure communication channels. Training shall cover the proper use of Multi-Factor Authentication (MFA) (e.g., not approving unexpected login prompts) and secure communication practices (e.g., verifying video conference links and not discussing confidential topics over unsecured lines).

This turns MFA fatigue into a training obligation, not a blame exercise. It allows the CISO to show that prompt bombing is covered in onboarding, refresher training, role-based training and privileged user briefings.

The same P38 Secure Communications and Multi-Factor Authentication (MFA) Policy also creates a monitoring obligation:

Information Security shall continuously monitor authentication logs for any single-factor login attempts or anomalous Multi-Factor Authentication (MFA) failures. Logs from secure communication systems, where applicable, shall be monitored for unauthorized access attempts or configuration changes.

For SMEs, P11S User Account and Privilege Management Policy - SME sets a practical baseline:

Multi-factor authentication (MFA) must be enabled, where technically feasible, for administrator accounts or sensitive systems.

The phrase “where technically feasible” should never become a loophole. If a system cannot support strong MFA, the exception must be recorded with an owner, expiry date, compensating controls, monitoring and a migration plan. Larger organizations can align the same expectation to P11 User Account and Privilege Management Policy, then test whether policy and operational reality match.

Detection evidence comes from P22S Logging and Monitoring Policy - SME, which requires authentication event logging:

Authentication logs: Successful and failed login attempts, session duration, MFA usage

It also requires urgent review of high-risk authentication signals:

Immediate review upon detection of high-severity alerts (e.g., malware, failed multi-factor authentication (MFA), repeated login failures)

Awareness must evolve as threats evolve. Information Security Awareness and Training Policy - SME supports that loop:

Topics must include emerging threats (e.g., phishing), relevant policy changes, and internal incident trends.

When the SOC detects MFA fatigue attempts, that intelligence should feed user alerts, helpdesk scripts, tabletop exercises and training updates.

A governed MFA fatigue control pack

Assume your organization uses a cloud identity provider, a SaaS CRM, a finance platform, a VPN, and a managed security provider. The goal is to govern MFA fatigue using Clarysec’s Zenith Blueprint, policy library and Zenith Controls cross-compliance guide.

Start with Step 19 in the Zenith Blueprint, which instructs teams to define authentication requirements per system and warns that password-only authentication should be avoided for administrative accounts, cloud consoles, remote access tools and internet-exposed systems. Then apply the practical review activity:

Review your MFA deployment: identify any gaps and plan to close them. Validate that service accounts are non-interactive where possible, have strong credentials, and are documented. Confirm no default credentials remain on any system or application.

Convert that guidance into an operating control pack.

Step 1: classify systems by authentication risk

Step 2: remove high-risk push behavior

For administrator and high-impact accounts, disable basic push approval. Use phishing-resistant authenticators where possible. Where push remains, enforce number matching, application context, geographic context, device binding and prompt rate limits. Block legacy authentication and require reauthentication for risky sessions.

Step 3: define alert rules for MFA fatigue

A practical SIEM rule should trigger when one or more of these patterns occurs within a short window:

• Three or more MFA push prompts for one user.
• Two denied prompts followed by one approved prompt.
• MFA approval from a new geography or unmanaged device.
• MFA prompt following a password spray or credential stuffing signal.
• MFA approval for privileged access outside normal working hours.
• New authenticator registration shortly after failed login attempts.

The alert should create an incident ticket, notify the SOC or security lead, and require containment steps: suspend session, revoke refresh tokens, require password reset, verify device, interview user, review access during the session, and classify whether personal data or critical service impact occurred.

Step 4: link privacy and incident records

If the account can access personal data, apply PII Security and Access Control Policy. It requires strong authentication before high-impact PII access:

[Both] The Information Security Lead MUST require strong authentication for privileged, remote, administrative or high-impact PII access before such access is enabled and record the requirement in REG12.

It also requires logging scope to be defined:

[Both] The System Owner / Application Owner MUST define the PII logging scope for authentication events, access events, privileged actions, PII export activity and material configuration changes in REG12 before production use or material change.

When monitoring suggests unauthorized PII access, it creates an incident record obligation:

[Conditional] The Incident Response Coordinator MUST open or link a REG10 record within one business day when monitoring indicates suspected unauthorized PII access, suspected PII disclosure, suspected PII alteration or suspected PII availability loss.

The privacy escalation is completed by PII Incident and Breach Management Policy:

[Conditional] The Privacy Lead / PIMS Manager MUST evaluate applicable legal, sectoral, financial-sector, cybersecurity, contractual, customer, and service-recipient reporting triggers for each high-impact PII incident and record the applicability outcome in REG01, REG08, and REG10.

This is what turns an MFA alert into audit-ready evidence across security, privacy and compliance.

NIS2, DORA and GDPR: one incident, different questions

MFA fatigue is a useful cross-compliance stress test because it touches governance, cyber hygiene, access control, incident detection, supplier access and breach reporting.

NIS2: management accountability and cyber hygiene

NIS2 applies to many essential and important entities, depending on sector, size and Member State designation. Article 20 places accountability on management bodies to approve cybersecurity risk-management measures, oversee implementation and receive training. Article 21 requires appropriate technical, operational and organizational measures, including incident handling, cyber hygiene, supply-chain security, access control, asset management, training, and multi-factor or continuous authentication where appropriate. Article 23 introduces staged incident reporting obligations for significant incidents, including early warning within 24 hours of becoming aware and incident notification within 72 hours.

A push bombing incident therefore becomes a board-level question: was MFA securely designed, or merely enabled?

DORA: authentication as digital operational resilience

For covered financial entities, DORA applies from 17 January 2025. It expects ICT risk management, detection, response, recovery, incident reporting, digital operational resilience testing and ICT third-party risk management.

DORA Article 9 addresses protection and prevention, including access control and authentication measures. Article 10 addresses detection of anomalous activity. Article 17 requires an ICT-related incident management process. In a DORA context, MFA fatigue evidence should show that affected ICT assets were identified, monitoring detected anomalous behavior, the incident was classified using impact criteria, senior management was escalated where required, and lessons learned were fed back into the ICT risk framework.

GDPR: security of processing and accountability

GDPR Article 5(1)(f) requires integrity and confidentiality. Article 5(2) requires accountability. Article 32 requires security appropriate to risk. Article 4 defines a personal data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.

If an MFA fatigue incident touches personal data, the evidence question is simple: can the organization demonstrate appropriate authentication controls, monitoring, incident response and breach assessment?

Crosswalk for ISO, NIST CSF 2.0, COBIT 2019 and audit evidence

NIST CSF 2.0 is useful because it translates MFA governance into GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER outcomes.

COBIT 2019 adds governance clarity. A COBIT-oriented auditor may look to DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security and MEA03 Managed compliance with external requirements. The focus is not the MFA vendor. It is whether authentication supports business objectives, whether access rights are governed, whether monitoring is effective, and whether management receives meaningful assurance.

A consolidated mapping helps compliance teams avoid fragmented evidence requests:

What auditors and regulators will ask for

A strong MFA fatigue program should survive multiple audit styles. Clarysec’s Zenith Controls cross-compliance guide shows how ISO/IEC 27002:2022 controls are tested across ISO, NIST, COBIT and ISACA methodologies.

A weak program says, “We asked the user and reset the password.” A governed program produces a SIEM alert, incident ticket, session revocation record, password reset evidence, MFA factor review, access log analysis, PII assessment, reporting trigger evaluation, root cause statement, corrective actions and management review input.

A 30-day action plan for MFA fatigue governance

The goal is not perfection in 30 days. The goal is visibility, ownership and evidence.

Week 1: identify and scope

• List all identity providers, VPNs, cloud consoles, SaaS platforms and privileged access tools.
• Identify systems with personal data, financial data, production access or service-impacting functions.
• Export current MFA methods and exceptions.
• Identify external and supplier accounts.
• Add MFA fatigue and push bombing to the risk register.
• Assign a risk owner and treatment owner.

Week 2: harden authentication

• Disable legacy authentication.
• Require phishing-resistant MFA for administrators where feasible.
• Enable number matching and application context for push MFA.
• Apply conditional access for location, device compliance and impossible travel.
• Limit repeated push prompts.
• Require reauthentication for high-risk actions.
• Make service accounts non-interactive where possible.
• Document exceptions with expiry and compensating controls.

Week 3: monitor and rehearse

• Ensure authentication logs capture success, failure, session duration and MFA usage.
• Create alert rules for repeated prompts, denied prompts followed by approval, new device registration and unusual location.
• Test alerts with a controlled simulation.
• Validate incident ticket creation and escalation.
• Train users with a short “unexpected MFA prompt” exercise.
• Update helpdesk scripts to prevent social engineering during password resets and MFA re-enrollment.

Week 4: evidence and management review

• Store configuration exports and screenshots.
• Record access review outcomes.
• Link training completion to privileged users.
• Review incidents and near misses.
• Update the Statement of Applicability and treatment plan.
• Present residual risk and metrics to management.
• Schedule internal audit sampling.

Make MFA fatigue auditable before it becomes reportable

MFA fatigue is a reminder that security controls fail at the seams: between identity and monitoring, between policy and training, between suppliers and internal access, between incident response and privacy reporting.

The organizations that manage it well do not simply “turn on MFA.” They govern authentication as a lifecycle, monitor it as a threat signal, train users as part of the control, and preserve evidence as part of the ISMS.

Clarysec brings three assets together:

• The Zenith Blueprint: An Auditor’s 30-Step Roadmap, especially Step 19 for secure authentication, Step 22 for authentication information, and Step 16 for personnel-driven incident reporting.
• Clarysec policy templates, including P38 Secure Communications and Multi-Factor Authentication (MFA) Policy, P22S Logging and Monitoring Policy - SME, P11S User Account and Privilege Management Policy - SME, Information Security Awareness and Training Policy - SME, PII Security and Access Control Policy, and PII Incident and Breach Management Policy.
• Zenith Controls: The Cross-Compliance Guide, which maps ISO/IEC 27002:2022 controls 5.17, 8.5, 8.15 and 8.16 to supporting controls, ISO audit expectations, GDPR, NIS2, DORA, NIST and COBIT.

If you are a CISO, compliance manager, auditor or business owner, run a one-week MFA fatigue evidence review. Pull your MFA configuration, authentication logs, privileged access list, supplier access list, incident playbook, training material and exception register. If those artefacts do not tell one coherent story, Clarysec can help you build the control pack before an attacker, auditor or regulator asks for it.

Explore the Zenith Blueprint, review Zenith Controls, or schedule a Clarysec discovery call to turn MFA fatigue from a board-level surprise into a defensible, auditable authentication program.