MFA Fatigue Attack Response Checklist for Oncology Pharmacy Compounding Systems

An MFA fatigue attack can turn repeated sign-in requests into a risk to pharmacy systems, patient information, and time-sensitive oncology workflows. Use this checklist to respond promptly, protect accounts, and maintain safe operations without bypassing your organization’s security or compounding procedures.

What should staff do when unexpected MFA prompts appear?

• Do not approve the prompt. If you did not initiate the sign-in, deny or ignore the request. CISA describes MFA fatigue, also called push bombing, as repeated authentication prompts intended to pressure someone into approving access; see its MFA number-matching guidance.
• Do not share verification codes or respond to unexpected calls or messages asking you to approve a request, disclose a code, or change your password.
• Report it promptly through your pharmacy’s approved security or incident-reporting channel. Include the approximate time, number of prompts, account or system involved, and whether you denied or accidentally approved one.
• If you approved a prompt, report that immediately. Tell the security team which account and device were involved. Do not conceal the approval or try to investigate the activity yourself.
• Preserve relevant evidence. Keep notifications or screenshots if permitted by policy, but do not send patient information through unapproved channels or delete suspicious alerts before the response team can review them.

An unexpected prompt is a warning sign, not by itself proof that an account was accessed or patient information was exposed. Follow your organization’s incident process while the security team investigates suspected security incidents.

How should pharmacy teams secure suspected compromised accounts and sessions?

Notify the incident lead, IT or security team, and pharmacy leadership. Ask the authorized response team to assess the account and connected systems, preserve relevant logs, and contain access using the organization’s procedures. HIPAA-covered entities must have procedures to identify and respond to suspected or known security incidents, mitigate harmful effects where practicable, and document incidents and outcomes, as described in HHS’s HIPAA Security Rule summary.

• Terminate unauthorized sessions. Have administrators revoke active sessions and, where applicable, refresh tokens or other access credentials. Check sign-in history and connected applications for activity the user does not recognize.
• Review MFA device registration revocation. Remove registrations that the account holder and security team cannot verify. Re-register a legitimate device only through the organization’s identity-verification process.
• Coordinate account credential rotation. Change affected passwords and any other potentially exposed credentials as directed by security staff. Use a trusted device and approved password-reset route, not a link in an unexpected message.
• Assess linked accounts and privileges. Review single sign-on, administrator access, shared accounts, service accounts, and integrations that could provide further access. Disable or restrict access when the response team determines it is necessary.
• Coordinate system isolation with pharmacy operations. The incident lead may need to isolate a workstation, network segment, or prescribing and IV-compounding interface. Agree on the containment action with IT and clinical leaders so it limits exposure without creating an unmanaged patient-care risk.

Avoid wiping or rebuilding a device before the response team has considered evidence preservation. The appropriate containment action depends on the suspected access, affected systems, and operational risk; NIST’s current incident-response guidance places incident response within an organization’s broader cybersecurity risk-management activities.

How can teams assess patient information and clinical care impacts?

Security and privacy staff should work with pharmacy and clinical leaders to determine what the account could access and what activity occurred during the relevant period. Review available sign-in, audit, application, and interface records for access, changes, exports, or attempted access; record what is known and what remains uncertain.

• Assess information exposure. Determine whether protected health information may have been viewed, acquired, changed, deleted, or disclosed, and which patients or records may be involved. Do not treat an MFA prompt alone as confirmation of a breach.
• Check clinical records and workflow activity. Look for altered, missing, duplicated, delayed, or misrouted prescriptions and orders; changes to patient or regimen details; and unexpected edits to verification or compounding records.
• Reconcile care affected during the incident. Ask the responsible oncology clinicians and pharmacists to review any uncertain orders, preparations, handoffs, or treatment delays through established clinical procedures. Do not infer that a prescription or preparation is correct merely because it appears in a system.
• Document decisions and follow-up. Record the time period reviewed, systems and logs checked, clinical concerns identified, corrective actions, and unresolved questions.

Route potential privacy exposure to the organization’s privacy officer or designated breach-response team. Under HHS guidance, a HIPAA breach determination may require assessing factors such as the information involved, who received or used it, whether it was actually viewed or acquired, and how the risk was mitigated; not every security alert automatically establishes a reportable breach. See the HHS Breach Notification Rule guidance.

Which oncology compounding systems require downtime procedures?

Use the incident team’s assessment to determine which systems are affected, which depend on them, and whether each can be trusted. A suspected account compromise may affect more than the application that generated the MFA prompt, but it does not automatically mean every pharmacy system must be shut down.

• Identity and access: MFA services, single sign-on, directory services, remote access, and privileged accounts.
• Prescribing and clinical records: electronic health records, oncology treatment plans, order entry, prescription verification, and medication histories.
• Compounding and verification: IV-compounding applications, dose or workflow checks, preparation records, barcode systems, and label printing.
• Connected services: prescribing and IV-compounding interfaces, interface engines, pharmacy networks, inventory tools, and other systems that exchange order or preparation information.

Identify the systems that require downtime procedures by checking the organization’s dependency map and the response team’s findings. If an interface or device may be compromised, coordinate prescribing and IV-compounding interface isolation with IT and pharmacy leadership. Do not rely on data from a system until the responsible team has assessed its integrity.

How can staff maintain safe compounding operations during an outage?

Activate only the organization’s approved oncology pharmacy downtime procedures and use current, controlled forms. Assign an incident lead and make sure staff know how to verify orders, communicate with prescribers, escalate clinical questions, and record work completed while systems are unavailable.

• Use sterile compounding production worksheets approved for downtime. Record enough information, according to local policy, to identify the patient and order, document the preparation and required checks, and support safe handoff and later reconciliation.
• Verify orders through an approved, trusted channel. If the source record or its integrity is uncertain, contact the prescriber or responsible clinician using verified contact information and follow the organization’s order-verification process.
• Use the organization’s required independent checks for patient, order, preparation, labeling, and handoff. Document who performed each check and when, as directed by local policy.
• Control and reconcile downtime records. Use the current form version, track completed and pending work, protect forms containing patient information, and reconcile each record into the appropriate system when authorized service returns.
• Stop and escalate when essential information cannot be verified or the team cannot maintain required quality and safety controls. Do not bypass authentication or clinical safeguards to keep production moving.

Follow applicable laws, standards, and your organization’s compounding procedures; the official USP General Chapter <797> page identifies the chapter on pharmaceutical compounding of sterile preparations. Downtime worksheets should be approved for your site rather than improvised during an outage.

What validation is required before restoring systems?

Do not return a system to routine use solely because it is reachable again. The authorized security and system owners should establish that the suspected access path has been addressed and that the system and its data are suitable for the pharmacy workflow.

• Confirm account recovery: unauthorized sessions and registrations have been removed, required credentials have been rotated, and access is restored only for verified users and devices.
• Confirm system security and integrity: IT has completed the organization’s required checks, reviewed relevant logs, and assessed affected connections and interfaces.
• Perform backup data integrity validation before relying on restored information. HHS’s ransomware and HIPAA guidance emphasizes contingency planning, recovery, and testing backup restoration.
• Test critical workflows using the organization’s approved validation process, including order receipt, verification, compounding documentation, labels, and relevant interfaces.
• Reconcile downtime work with restored electronic records. Resolve duplicate, missing, or conflicting entries and document completion according to local procedures.
• Obtain operational sign-off from the designated security, IT, pharmacy, and clinical leaders before resuming affected workflows. Monitor the systems after restoration and escalate unexpected activity.

These are operational safeguards, not a universal federal checklist for system release. HIPAA requires applicable covered entities to maintain contingency and security-incident procedures; the organization should define its own restoration criteria for each system and clinical workflow.

How should pharmacies prepare and review their incident-response plan?

Make the response plan usable during a busy shift, after hours, and when routine communication systems are unavailable. HIPAA’s Security Rule includes security-incident procedures and contingency planning for systems containing electronic protected health information; HHS describes requirements for incident response, data backup, recovery, and emergency operations in its Security Rule summary.

• Assign clear roles and contacts. Identify pharmacy, IT/security, clinical, privacy, facilities, and vendor contacts, including who can authorize containment and system restoration.
• Map systems and dependencies. Document which prescribing, compounding, verification, identity, network, and interface services support each critical workflow.
• Set practical response triggers. Define how staff report unexpected prompts, suspected approvals, account changes, possible data exposure, and outages, and when leadership should activate downtime procedures.
• Maintain and control downtime resources. Keep approved worksheets and instructions accessible, current, and protected, with a process for version control and post-outage reconciliation.
• Exercise the plan. Practice a MFA fatigue scenario that includes unauthorized session termination, account credential rotation, MFA device registration revocation, interface isolation decisions, clinical-impact review, and restoration sign-off.
• Review findings and update procedures. Document the incident and response, address identified gaps, and revise training and procedures as needed. HHS’s OCR cyber-attack checklist also advises organizations to execute response and mitigation procedures and contingency plans.

Keep the plan specific to your systems, staffing, and clinical workflows. An organization’s procedures should make clear who decides whether to continue, pause, isolate, or restore each affected service.

FAQs.

Should staff approve an MFA prompt they did not initiate?

No. Deny or ignore the prompt, do not share any verification code, and report it promptly through your organization’s approved security channel. If you approved it accidentally, report that immediately so the response team can secure the account.

How should an unauthorized MFA device registration be removed?

Contact the organization’s IT or security team and ask an authorized administrator to verify the account, remove the unrecognized registration, review related sign-in activity, and terminate unauthorized sessions. Add a legitimate replacement device only through the organization’s approved identity-verification process.

When can oncology compounding systems return to service?

Return an affected system to service only after the authorized response team has addressed suspected unauthorized access, validated system and backup data integrity as applicable, tested critical workflows, reconciled downtime activity, and obtained required operational approval. Follow your organization’s restoration criteria; system availability alone does not establish that its data can be trusted.

What information should downtime compounding forms record?

Use your site’s approved form and policy. The form should support identification of the patient and order, documentation of the preparation and required checks, labeling and handoff, and reconciliation into the electronic record. Follow local requirements for recording staff, dates and times, product or preparation details, and any other information needed to maintain traceability and safe continuity of care.

In short, do not approve unexpected prompts, secure suspected accounts through authorized responders, assess both data exposure and clinical impact, follow approved downtime procedures, and restore systems only after required validation and sign-off.