MFA Fatigue Attack on a Ventilator Waveform Server: Incident Response Checklist

This checklist is for a suspected MFA fatigue attack—also called MFA push bombing—involving a ventilator waveform server, gateway, or its supporting identity systems. Treat it as a coordinated cybersecurity and patient-safety incident: clinical leaders should guide care decisions, while technical teams investigate and contain access under approved procedures.

Do not assume that a compromised account means a ventilator or waveform server has been compromised. Conversely, do not assume that patient care is unaffected until clinical and technical teams verify the system’s status. Follow your organization’s emergency procedures and the device manufacturer’s instructions.

How should clinical and technical teams coordinate the response?

Activate the organization’s incident-response process and name an incident lead. Include clinical leadership, respiratory therapy, clinical engineering or biomedical engineering, IT and security, identity administrators, the system owner, privacy or compliance, and communications or risk management as appropriate. Contact the device or system manufacturer through established support channels if its equipment or guidance may be relevant. The FDA’s medical-device cybersecurity guidance emphasizes shared responsibility between healthcare delivery organizations and manufacturers, and its incident-preparedness resources identify cross-functional participation as important.

• Clinical lead: Assess patient-care impact, identify affected units and patients, and decide whether clinical downtime procedures are needed.
• Technical lead: Investigate the identity provider, server, gateway, network, and connected systems; preserve evidence; and propose containment options.
• Clinical engineering and system owner: Confirm device and waveform-system dependencies, safe operating limits, and manufacturer-approved actions.
• Incident lead: Maintain a time-stamped decision log, assign owners, and coordinate status updates and escalation.

Use one approved communication channel for incident coordination. Share only the patient information necessary for response, and keep clinical care decisions with authorized clinical personnel. The HIPAA Security Rule requires covered entities and business associates to have procedures for identifying and responding to security incidents and documenting incidents and their outcomes; see the HHS summary of the HIPAA Security Rule.

What MFA fatigue indicators should staff report?

Tell staff to report any authentication request they did not initiate, even if only one prompt appeared. Report repeated prompts, prompts arriving while away from a login screen, unexpected login or password-reset alerts, and messages asking the user to approve a request or share a code. Staff should report whether they denied, ignored, or accidentally approved a prompt.

Other warning signs include unfamiliar sign-in locations or devices, unexpected MFA-method enrollment, account-recovery notifications, password changes the user did not make, and unfamiliar vendor or administrator activity. CISA describes MFA fatigue, or push bombing, as repeated mobile push notifications intended to pressure someone into approving an attacker’s login. Its joint advisory on credential-access activity also describes attackers registering their own MFA devices after gaining account access.

Staff should deny an unrequested prompt, avoid replying to suspicious messages, and report the event promptly using the organization’s established channel. If they approved a prompt by mistake, they should say so immediately; they should not try to investigate or conceal it themselves.

Which containment actions protect access without disrupting ventilator support?

Contain the identity or network access involved, not the clinical service by default. Before making changes that could affect the waveform server, gateway, monitoring, or vendor support, have the clinical lead and system owner assess the likely care impact. Do not disconnect, reboot, isolate, or reconfigure medical equipment or its supporting infrastructure unless authorized clinical engineering or the manufacturer’s approved procedure directs that action.

• Stop further approvals by telling affected users to deny unexpected prompts and report them. Use a verified contact method to reach the identity or security team.
• From a trusted administrative workstation, review the affected account and restrict or disable it if the incident lead and clinical service owner determine that doing so will not remove necessary clinical access without a safe alternative.
• Remove unauthorized MFA methods, recovery options, or newly registered devices. Reset credentials through the organization’s approved process, using a clean device.
• Assess whether authentication session token revocation is needed. Revoke compromised tokens and sessions in a coordinated way, but account for separately managed application sessions: ending an identity-provider session may not end an application session, and vice versa. NIST explains this distinction in its guidance on session management.
• Limit or suspend suspected vendor access only after checking whether it supports an active clinical or technical need. Arrange an approved alternative contact or access path if required.
• Apply network restrictions only after confirming the system’s dependencies and the clinical consequences with the responsible teams.

Choose the narrowest effective containment action, document who approved it and when, and monitor the affected access path. If there is an immediate patient-safety concern, activate clinical emergency procedures first while the response team coordinates technical actions.

What logs and records should investigators review?

Preserve relevant records promptly, using authorized tools and the organization’s evidence-handling procedures. Record the time zone, collection time, source system, collector, and any steps taken. NIST recommends safeguarding incident-response records and preserving the integrity and provenance of incident data in Special Publication 800-61 Revision 3.

• Identity provider audit logs: Review sign-in attempts, MFA prompts and outcomes, device or authenticator enrollment, password resets, recovery events, session activity, and account or policy changes.
• Privileged account activity: Check role assignments, administrator elevation, configuration changes, creation of accounts or credentials, and access to management consoles. Look for signs of privileged account escalation.
• Ventilator gateway access logs: Review successful and failed logins, remote-support sessions, configuration or software changes, and connections from unexpected devices or network locations, if those records are available.
• Server and application records: Examine operating-system, waveform-server, application, database, and audit logs for unusual access, exports, changes, service interruptions, or missing records.
• Network and endpoint records: Correlate firewall, VPN, DNS, endpoint-detection, remote-access, and relevant workstation logs to identify source systems and related activity.
• Incident and care records: Keep a time-stamped incident timeline, decisions and approvals, staff reports, system status, downtime actions, vendor communications, and documented patient-care impacts.

Coordinate log collection with privacy, compliance, and legal personnel as appropriate, and protect records from unauthorized access or alteration. Do not delay an urgent action needed to protect patients or stop active compromise solely to complete routine evidence collection; preserve what is feasible and document the timing and reason for each action.

How can teams maintain patient-care continuity during an incident?

Use the organization’s clinical system downtime procedures if the waveform server or related access becomes unavailable or cannot be trusted. The clinical lead should identify the approved method for ongoing assessment and monitoring, communicate any workflow changes to affected staff, and confirm who is responsible for patient-care decisions. Do not substitute an unapproved device, connection, or monitoring method.

Keep clinical and security communications distinct but coordinated. Staff should know how to report a change in system availability or patient status without sending sensitive details through an unapproved channel. Clinical engineering should confirm whether a proposed containment action could affect device operation, alarms, monitoring, or support. Contact the manufacturer when technical or safety guidance is needed.

HHS identifies emergency-mode operation and continuity of critical business processes as elements of the HIPAA Security Rule contingency-plan standard. See HHS guidance on contingency planning. Apply the organization’s approved plan to the actual system and clinical environment rather than assuming that a generic workaround is safe.

What checks are required before restoring access?

Restore access only after the incident lead, identity team, system owner, and clinical representative agree that the relevant risk is controlled and the restoration will not create an avoidable patient-care interruption. Before reopening access, verify that:

• The affected account, device, and access path have been assessed, and unauthorized MFA methods, credentials, or sessions have been addressed.
• Any required password reset or authenticator re-enrollment was completed through a trusted process, with the user’s identity verified.
• Administrative and vendor access is limited to approved individuals and appropriate roles; remove temporary privileges that are no longer needed.
• The server, gateway, and relevant connections have been checked for unauthorized configuration or account changes, using manufacturer-approved procedures where applicable.
• Clinical engineering and the system owner confirm that monitoring, alarms, and required clinical workflows are operating as expected.
• Staff know how to report renewed prompts, access failures, unexpected changes, or clinical-system problems.

Test access in a controlled manner with the responsible system owner. Keep monitoring heightened during restoration, document approvals and test results, and maintain downtime procedures until the clinical lead confirms they are no longer needed.

How can the organization reduce the risk of repeat attacks?

Prioritize phishing-resistant multifactor authentication for privileged users and accounts with access to clinical infrastructure, where supported and clinically workable. CISA identifies phishing-resistant MFA as a stronger long-term measure and recommends number matching as an interim mitigation for organizations that still rely on push-based MFA and cannot immediately deploy phishing-resistant methods.

• Review MFA configuration, alerting, lockout, account-recovery, and authenticator-enrollment processes. Make it easy for staff to report unrequested prompts.
• Use role-based access and separate routine accounts from administrator accounts. Review vendor access regularly, restrict it to approved purposes, and remove access when it is no longer needed.
• Improve identity-provider and application logging, retention, alerting, and time synchronization so teams can detect and correlate suspicious activity.
• Inventory the waveform server, ventilator gateways, dependencies, owners, support contacts, and approved maintenance procedures.
• Exercise the incident-response and downtime plans with clinical, IT, security, and clinical-engineering participants. Update procedures based on exercise findings and real incidents.

In summary, treat suspected MFA push bombing as both an access incident and a potential patient-safety issue: coordinate across clinical and technical teams, preserve evidence, contain access carefully, maintain approved care workflows, and verify system and account integrity before restoring access.

FAQs.

What should staff do after receiving an unrequested MFA prompt?

Deny the prompt, do not share an authentication code, and report it promptly through the organization’s established channel. If you approved it accidentally, report that immediately as well. Use a verified contact method to reach the security or identity team.

Should active sessions be terminated before log preservation is complete?

Not automatically. Preserve relevant logs promptly where feasible, but do not let routine evidence collection delay action needed to stop an active compromise or protect patients. Coordinate session termination with the incident lead and clinical system owner, because identity-provider and application sessions may be managed separately and terminating access can affect clinical workflows.

How can teams contain the incident without interrupting ventilator monitoring?

Assess clinical impact before changing accounts, network connections, gateways, or servers. Prefer narrow access controls, such as addressing a compromised account or unauthorized authenticator, while the clinical lead and clinical engineering confirm that essential monitoring and approved support remain available. Use downtime procedures if needed, and do not disconnect or reconfigure medical equipment without appropriate authorization.

What should be verified before restoring staff and vendor access?

Confirm that unauthorized credentials, MFA methods, and sessions have been addressed; affected accounts and systems have been assessed; and access is limited to approved users and roles. Have the system owner and clinical engineering verify expected operation, and have the clinical lead confirm that required workflows are available. Document approvals, test results, and any temporary access conditions.