MFA Fatigue Attack Response Guide for Medicare Drug Integrity Contractors

How does an MFA fatigue attack target Medicare drug integrity contractors?

An MFA fatigue attack, also called push bombing, floods a person with sign-in approval prompts in the hope they will approve one by mistake or to stop the interruptions. The attacker may already have a username and password obtained through phishing, password reuse, or another credential attack. CISA’s guidance on phishing-resistant MFA describes this attack pattern.

For Medicare drug integrity contractors, an account may provide access to investigative systems, audit materials, or sensitive beneficiary, provider, and claims information, depending on the user’s role. CMS describes One Program Integrity as a system used by program integrity contractors and other authorized users to access tools and data for detecting and deterring fraud, waste, and abuse. CMS’s One Program Integrity privacy assessment lists examples of information that system queries may return.

If a user approves a fraudulent prompt, an attacker may sign in and try to maintain access by adding an authenticator, changing account-recovery details, or using existing sessions. Treat unexpected prompts as a possible warning of exposed credentials—not as proof that an attacker accessed data. Investigators should establish what happened from identity and system records.

What should staff do when unexpected MFA prompts appear?

Do not approve an MFA prompt you did not initiate. If the authenticator offers a deny or report option, use it; otherwise, leave the request unanswered and promptly contact your help desk or security team using a known, trusted channel. Do not follow links in unexpected messages or rely on a caller or chat message that asks you to approve a sign-in.

Tell the response team when the prompts began, how often they appeared, which account or service was named, and whether you approved, denied, or interacted with any request. Preserve relevant notifications or screenshots according to your organization’s policy, taking care not to expose protected information in an unapproved channel.

If you approved a prompt, entered credentials, or notice a new authenticator or recovery method, report that immediately. Use a trusted device and the organization’s verified recovery process; do not try to investigate by repeatedly signing in or changing settings on your own. CISA recommends phishing-resistant MFA as a stronger defense against push-fatigue attacks. CISA’s number-matching guidance identifies number matching as an interim mitigation when phishing-resistant MFA is not yet available.

How should teams contain a potentially compromised account?

Have authorized identity and security administrators assess the risk and contain the account under the incident-response plan. Depending on what the evidence shows, steps may include temporarily disabling sign-in, revoking active sessions and refresh tokens, blocking suspicious sign-ins, and resetting the password from a trusted device. A password reset alone may not end already-issued sessions, so responders should verify that sessions and tokens have also been addressed.

Review authenticator enrollment changes and remove any device the user does not recognize. Check recovery phone numbers and email addresses, delegated access, connected applications, API credentials, and privileged roles. Restore access only through a verified process, then require the user to enroll an approved authenticator and confirm that suspicious activity has stopped.

Containment should limit further access while preserving evidence where practicable. For CMS contractors, use the reporting channels and timelines that apply to the contract and incident type. CMS’s Breach Response Plan states that contractors must report suspected breaches within one hour of discovery; responders should confirm the applicable contract requirements and promptly involve the designated CMS contacts.

Which authentication and system activity should investigators review?

Review authentication challenge logs for repeated prompts, denied and approved challenges, sign-in successes and failures, timestamps, source IP addresses, device details, user agents, and any available location or risk signals. Compare activity with the staff member’s normal patterns, but treat location or device indicators as leads rather than conclusive proof of identity.

Check authenticator enrollment changes, password resets, recovery-method changes, account unlocks, and changes to identity and access management settings. Then trace sessions and access to connected services: identify which systems were reached, what records or files were viewed or exported, and whether permissions or data were changed.

Look for persistence or follow-on activity, including new application authorizations, delegated access, API tokens, mailbox or forwarding rules, and activity by accounts with elevated privileges. When systems contain electronic protected health information, the HIPAA Security Rule includes audit-control and information-system activity review requirements for regulated entities. HHS’s guidance on HIPAA audit controls describes recording, examining, and regularly reviewing system activity.

How can teams preserve evidence and coordinate incident response?

Record a timeline of reported prompts, containment actions, account changes, and relevant sign-ins. Export authentication challenge logs, identity-provider records, endpoint and network alerts, and relevant application audit trails before routine retention processes overwrite them. Preserve original records and metadata where possible, restrict access to evidence, and document who collected or handled it and when. NIST’s incident-response guidance recommends preserving the integrity and provenance of incident data and response records.

Coordinate security, identity administrators, privacy officials, legal counsel, system owners, and the contract’s designated CMS contacts. Determine what information may have been accessed, by whom, and over what period. Share evidence and incident details only through approved channels, and follow the organization’s retention, privacy, and evidence-handling procedures.

HIPAA-regulated entities must have procedures to identify and respond to suspected or known security incidents, mitigate harmful effects where practicable, and document incidents and outcomes. Those requirements do not make every unexpected MFA prompt a confirmed disclosure, and HIPAA does not establish one universal reporting deadline for every incident. Apply the specific contract, CMS, and regulatory reporting rules that govern the organization. HHS’s explanation of the Security Rule’s incident procedures summarizes these responsibilities.

What MFA and access controls reduce the risk of repeated attacks?

Prioritize phishing-resistant authentication, such as appropriately configured security keys or passkeys based on public-key cryptography. NIST explains that phishing resistance binds authentication to the legitimate verifier or session, while manually entered one-time codes are not considered phishing-resistant under its guidance. NIST’s current Digital Identity Guidelines describe these distinctions.

If phishing-resistant methods are not yet available, consider number matching and rate limits for push challenges as interim safeguards. These controls can make accidental approvals less likely or reduce prompt abuse, but number matching is not equivalent to phishing-resistant authentication. CISA’s number-matching fact sheet makes this distinction.

Use least-privilege access so staff can reach only the systems and data needed for assigned work, and review access when roles change. Strengthen identity and access management with alerts for authenticator enrollment changes, password or recovery-method updates, suspicious sign-ins, and unusual access to sensitive records. Require verified identity checks for account recovery and new authenticator enrollment, and routinely review privileged accounts and connected applications. These are risk-reduction practices; apply them alongside the organization’s policies and applicable CMS contract requirements.

In short, staff should never approve an unrequested prompt; responders should promptly contain accounts, examine authentication and system activity, preserve evidence, and report through the required channels. Phishing-resistant authentication, careful authenticator management, and least-privilege access can help reduce the risk of repeat attacks.

FAQs.

Should staff approve an MFA prompt they did not initiate?

No. Do not approve it. Use a deny or report option if available, then promptly notify the help desk or security team through a trusted channel.

What account-containment steps should responders take after a suspected MFA fatigue attack?

Responders should assess the account, revoke active sessions and tokens, restrict or disable sign-in as appropriate, reset credentials through a trusted process, remove unauthorized authenticators, and verify recovery details and connected access. They should also review activity for signs of unauthorized access and follow applicable reporting requirements.

Which sign-in and account-change records should investigators preserve?

Preserve authentication challenge logs, sign-in successes and failures, timestamps, available IP and device details, authenticator enrollment and removal events, password and recovery changes, session activity, and relevant application or data-access logs. Retain associated metadata and document evidence handling under organizational procedures.

How can contractors reduce repeated MFA prompts and suspicious sign-ins?

Prioritize phishing-resistant authentication, and use number matching and challenge rate limits as interim measures when necessary. Combine these controls with least-privilege access, monitoring for suspicious sign-ins and authenticator enrollment changes, verified recovery procedures, and regular access reviews.