MFA Fatigue Attack Response Guide for Interactive Patient Care System Vendors

How do MFA fatigue attacks target interactive patient care system vendors?

An MFA fatigue attack—also called push bombing—uses stolen or phished credentials to trigger repeated multifactor authentication prompts. The attacker hopes the account holder will approve one by mistake, out of frustration, or after being persuaded by a convincing phone call or message.

For vendors supporting interactive patient care systems, an approved prompt could give an attacker access to a vendor portal, remote support tool, VPN, cloud console, or technician account. From there, the attacker may attempt to reach customer environments, alter account settings, create additional credentials, or access systems and information beyond the initial account.

Repeated prompts do not by themselves prove that an account was compromised. They are, however, a reason to treat the credentials and the account’s active sessions as potentially exposed until responders investigate. CISA’s guidance on implementing number matching describes MFA fatigue and recommends phishing-resistant MFA as a stronger defense, with number matching as an interim mitigation when phishing-resistant methods are not available.

Patient care environments add an operational concern: a broad or hurried shutdown could interrupt support or affect service availability. Vendors should coordinate response decisions with the affected healthcare organization and follow established safety and incident procedures rather than changing or disconnecting a live care system without authorization.

What should users do when they receive repeated MFA prompts?

Do not approve an unexpected prompt. Do not accept it to silence notifications, and do not share a one-time code or number displayed by an authentication flow. If the prompt uses number matching, enter a displayed number only when you personally initiated the sign-in and have verified that it is the intended request.

1. Deny the prompt if that option is available. Do not interact with links or phone numbers in a related message that you did not expect.
2. Report it promptly through a trusted channel. Contact your organization’s security team, help desk, or incident hotline using a known internal number or approved reporting tool. Include the time, account, prompt type, and whether you approved or denied any request.
3. Stop using the affected account for new sign-ins until instructed. If you entered your password into a suspicious page or approved a prompt, tell responders clearly. Do not assume that denying later prompts reverses an earlier approval.
4. Preserve relevant details. Keep the notification or message if organizational policy allows, and avoid deleting or resetting anything before responders advise you.

Responders may ask you to change the password from a trusted device, re-enroll an authenticator, or verify recent account activity. Follow the approved recovery process; do not accept unsolicited help-desk calls or disclose authentication codes. NIST’s current Digital Identity Guidelines distinguish phishing-resistant authentication from methods whose outputs can be relayed to an impostor, supporting the use of stronger methods where the risk warrants them.

How should vendors contain a potentially compromised account?

Use the incident-response plan and assign an incident lead. First establish whether a prompt was approved, whether the account completed a sign-in, and whether that sign-in reached any vendor or customer system. Coordinate with affected customers when their environments, service availability, or data may be involved.

1. Restrict access proportionately. Disable or suspend the suspected account, block risky sign-ins, or remove relevant access while responders assess the threat. For a privileged or remote support account, consider limiting its access to the affected customer environment.
2. Terminate active access. Revoke active sessions and refresh tokens where the identity platform supports it, then verify that connected applications and remote access tools no longer accept existing sessions. A password change alone may not end every already-authenticated session.
3. Secure the authentication methods. Review registered authenticators, recovery methods, delegated access, and newly added devices. Remove unauthorized methods and use an identity-verified process before re-enrolling the legitimate user.
4. Check for persistence or privilege changes. Look for new accounts, changed roles, added application consents, modified access policies, altered recovery details, and new credentials or keys associated with the account.
5. Protect evidence and document actions. Preserve logs and relevant system state before making changes when feasible. Record what responders did, when they did it, and the basis for restoring access.

Containment should account for patient-care operations. If a vendor account supports a live system, work with the customer’s designated technical and clinical contacts to select a safe alternative support path or temporary control. NIST’s incident response guidance recommends planning containment and recovery actions according to incident impact, including the effects on critical services.

If the vendor handles electronic protected health information on behalf of a covered entity or another business associate, follow the applicable agreement and incident-reporting process. HIPAA obligations depend on the parties’ roles and circumstances; they should not be reduced to a blanket claim that every technology vendor is subject to the same duties. See 45 CFR § 164.308 for Security Rule administrative safeguards, including security incident procedures and business associate provisions.

Which sign-in records and remote access activity should responders investigate?

Build a timeline around the first unexpected prompt, any credential entry or approval, and the first successful sign-in. Preserve relevant records before retention limits or routine cleanup remove them. Use a consistent time zone and correlate records across identity, network, endpoint, application, and customer systems.

• Authentication challenge logs: prompt volume and frequency, challenge results, denials and approvals, request identifiers, authentication method, policy outcome, and the source device, IP address, or location when recorded.
• Sign-in and identity changes: failed and successful logins, unusual devices or locations, password resets, new authenticator enrollment, recovery-method changes, new sessions, application consent, role changes, and token or session revocation events.
• Remote access records: VPN, virtual desktop, remote support, remote-management, and service-desk logs; connection start and end times; source and destination; the target customer or system; and commands or actions recorded by the tool.
• System and application activity: configuration changes, privilege use, access to patient or customer data, file transfers, software deployment, account creation, and attempted access to other systems.
• Help-desk activity: password resets, identity verification, MFA re-enrollment, exception approvals, and any suspected help-desk MFA bypass or social-engineering request.

Compare the suspected activity with the user’s normal role, schedule, assigned customers, devices, and support ticket or change request. Look for impossible or overlapping sessions, activity outside the approved service window, and connections that continued after a user believed they had signed out.

For systems containing or using ePHI, the Security Rule includes requirements concerning audit controls and authentication, while administrative safeguards include regular review of information-system activity records. See 45 CFR § 164.312 and 45 CFR § 164.308. Keep investigations focused on information needed to determine scope, exposure, and operational impact, and protect the collected records from unauthorized access or alteration.

How can vendors secure remote access to patient care systems?

Make remote access a controlled, attributable support function—not a standing pathway from a vendor account into customer systems. Require each person to use an individual identity, and grant only the access needed for an approved task, customer, and time period.

• Use phishing-resistant authentication where practical. Prefer methods that bind authentication to the legitimate service, such as appropriately deployed security keys or platform authenticators. NIST explains that manually entered outputs, including one-time passcodes, are not considered phishing-resistant because they can be relayed to an impostor.
• Use number matching as a fallback, not an equivalent substitute. Where push-based MFA remains in place, require number matching if supported and provide a clear way to report unexpected prompts. CISA describes number matching as a mitigation for MFA fatigue when phishing-resistant MFA cannot yet be implemented.
• Require a managed access path. Route connections through approved gateways or remote access services, apply device and account checks, and restrict reachable systems by customer, role, and approved maintenance window.
• Limit unattended remote sessions. Avoid persistent or unattended remote sessions when they are not necessary. Use short-lived access, session timeouts, customer authorization where appropriate, and visible session records.
• Monitor and record access. Log successful and failed authentication, connection start and end times, session activity, and changes made. Protect logs centrally and limit access to them.
• Plan for safe interruption and recovery. Document how customer staff can suspend vendor access and how support can continue safely if a remote tool or account is disabled during an incident.

CISA’s remote access guidance recommends monitoring authentication and access events and establishing procedures to handle alerts. For healthcare settings, HHS OCR’s cybersecurity guidance emphasizes risk-based safeguards and identifies MFA for higher-risk remote access as a security measure organizations may consider. HIPAA does not make a single MFA technology the universal solution; regulated entities select and document safeguards based on their risk analysis.

What MFA controls and staff training help prevent repeat attacks?

Build prevention around reducing the value of a stolen password, limiting what an approved prompt can unlock, and helping people report suspicious activity quickly.

• Adopt phishing-resistant authentication for higher-risk accounts. Prioritize administrators, remote support staff, and accounts that can access customer environments or sensitive information. Test enrollment, account recovery, and emergency access before expanding deployment.
• Enable number matching and rate limits where push MFA remains. Use controls that make accidental approval harder, restrict repeated challenges, and alert on bursts of prompts or unusual sign-in attempts.
• Reduce standing privilege. Use least privilege, separate administrative accounts from everyday accounts, and provide time-limited elevation for approved tasks.
• Strengthen identity recovery and help-desk workflows. Verify the requester through established procedures before resetting credentials, bypassing MFA, or registering a new authenticator. Require extra review for privileged accounts and record exceptions.
• Train staff on what to do, not just what to recognize. Explain that unexpected prompts must not be approved, identify trusted reporting channels, and practice reporting a suspected approval or credential disclosure without delay.
• Exercise the response process. Test account suspension, session and refresh token revocation, customer notification, safe remote-session shutdown, and restoration of legitimate access.

HIPAA’s security awareness and training program requirement applies to workforce members of covered entities and business associates, with periodic security reminders identified as an addressable implementation specification. It does not establish a universal federal annual certificate-renewal requirement for every staff member or vendor; organizations should follow applicable law, contracts, and their own employer-specific policies. See 45 CFR § 164.308.

In short, treat repeated MFA prompts as a security signal: users should deny and report them, responders should contain the account and investigate linked sessions, and vendors should reduce standing remote access while preserving safe patient-care operations. Phishing-resistant authentication, monitored remote access, sound recovery controls, and practical staff training help reduce the chance that one mistaken approval becomes a wider incident.

FAQs

Should staff approve an unexpected MFA prompt?

No. Staff should deny or ignore the unexpected prompt and report it through a trusted internal channel. They should never approve a request just to stop notifications or share a code with someone claiming to be support staff.

How can a vendor contain an account after a suspected MFA fatigue attack?

Temporarily suspend or restrict the account, revoke active sessions and refresh tokens where supported, secure or replace compromised credentials and authenticators, and check for new accounts, privileges, or recovery methods. Preserve evidence, coordinate with affected customers, and ensure any action involving a live patient-care system is planned with the appropriate customer contacts.

What sign-in activity should be reviewed during an investigation?

Review authentication challenge logs, failed and successful sign-ins, authenticator and recovery-method changes, session and token activity, remote access connections, help-desk resets, and actions taken in connected systems. Correlate timestamps and sources to determine whether an MFA approval led to access or further activity.

How can interactive patient care system vendors prevent MFA fatigue attacks?

Use phishing-resistant authentication for high-risk accounts where feasible, add number matching and challenge limits to push MFA where needed, minimize standing privileges, secure help-desk recovery, and monitor remote sessions. Train staff to reject unexpected prompts and report them quickly, and test incident procedures with customer safety and service continuity in mind.