MFA Fatigue Attack on a Transfusion History Database: Incident Response Checklist

An MFA fatigue attack can turn repeated sign-in prompts into unauthorized access if a staff member approves one. Use this checklist to assess the alert, contain compromised access, investigate possible exposure or changes to transfusion records, and keep clinical workflows safe while responders work.

How can repeated MFA prompts signal an attack?

Repeated MFA prompts that a user did not initiate may indicate that someone has obtained their password and is trying to sign in. Attackers may send a series of push requests hoping the user will approve one by mistake or out of frustration—a technique known as MFA fatigue or push bombing. Repeated prompts are a warning sign, but they do not by themselves prove that an account was accessed. CISA’s MFA number-matching guidance describes the attack and recommends phishing-resistant MFA, or number matching as an interim measure where appropriate.

• Ask the staff member whether they initiated any sign-in attempts and whether they approved, denied, or ignored a prompt.
• Record the approximate time, number of prompts, displayed application or location details, and any related calls or messages claiming to be from IT.
• Tell staff not to approve unexpected prompts, share verification codes, or respond to unsolicited support requests. They should report the alert using the organization’s established channel.
• Treat any approved unexpected prompt, unfamiliar sign-in, or change the user did not make as a possible compromise and escalate it promptly.

What sign-in and MFA logs should responders review?

Start with identity provider sign-in logs and MFA push notification logs for the affected account. Establish a time window that begins before the first suspicious prompt and continues through containment. Record the time zone and preserve the original event data where possible; product fields and retention periods vary by identity provider.

• Review sign-in outcomes, including successful, failed, blocked, interrupted, and MFA-challenged attempts. Compare event times with the user’s report of prompts.
• Check available context such as source IP address, approximate location, device, browser or client application, sign-in method, session details, and any risk or policy decisions recorded by the provider.
• Review MFA outcomes and registered methods: approvals, denials, timeouts, repeated requests, newly enrolled or removed authenticators, and authentication method changes.
• Look for password resets, account recovery, changed contact details, new devices, delegated access, or other identity changes around the same period.
• Correlate identity events with application, endpoint, network, email, and transfusion database audit logs. HIPAA’s Security Rule includes requirements for reviewing information-system activity and maintaining audit controls for systems containing ePHI; see 45 CFR § 164.308 and 45 CFR § 164.312.

Which containment steps should be taken first?

Coordinate containment with the incident lead, identity administrators, application owners, and clinical operations. Limit unauthorized access quickly, but account for any effect that a lockout or system restriction could have on patient care.

1. Contact the user through a trusted channel. Confirm whether they initiated or approved a request; do not rely on an incoming call, email, or message from someone claiming to be support.
2. Secure the account. If compromise is suspected, use a clean administrative workstation to reset credentials, block or disable the account as appropriate, remove unfamiliar authentication methods, and stop unauthorized recovery or enrollment activity.
3. Revoke active access. Apply session token revocation and invalidate active sessions or refresh tokens where the identity provider and connected applications support it. Confirm whether the transfusion database maintains separate sessions that must also be ended.
4. Protect other accounts and systems. Check for reuse of the same password, other affected accounts, suspicious forwarding rules or delegated access, and compromised devices. Isolate an endpoint if responders have evidence that it is involved and can do so without disrupting essential clinical functions.
5. Preserve evidence as containment proceeds. Capture relevant logs and administrative changes before routine retention or system activity overwrites them, when feasible. NIST’s SP 800-61 Rev. 3 incident response guidance emphasizes integrating response into cybersecurity risk management; containment choices should account for service availability and evidence preservation.

Document who authorized each action, what was changed, and when. Avoid broad shutdowns unless the incident commander and clinical leaders determine they are necessary to reduce risk.

How should responders investigate account activity and preserve evidence?

Build a timeline that links the user’s report, identity provider events, MFA activity, endpoint activity, and transfusion database audit logs. Keep an untouched copy of relevant records when possible, restrict access to evidence, and document collection times, sources, and handlers according to the organization’s incident procedures.

• Determine whether any sign-in succeeded after denied, ignored, or timed-out prompts. A string of denied prompts does not rule out a later successful sign-in, and a successful event should be checked against the account holder’s report and known work activity.
• Identify sessions, devices, applications, and authentication methods associated with the account. Check for newly enrolled authenticators, changed recovery details, and other authentication method changes that were not authorized.
• Review relevant application and transfusion database audit logs for reads, searches, edits, exports, printing, downloads, deletions, or permission changes, depending on what the system records.
• Preserve original timestamps, event identifiers, account names, source addresses, and available device details. Note any clock differences between systems when correlating events.
• Record gaps or limitations, such as unavailable logs, missing fields, or short retention. Ask the identity provider, database vendor, or other service providers to preserve and provide relevant records under applicable agreements and procedures.

HIPAA requires regulated entities to identify and respond to suspected or known security incidents, mitigate harmful effects to the extent practicable, and document incidents and outcomes. See 45 CFR § 164.308(a)(6).

How can teams assess access to transfusion records and functions?

Work with the transfusion service or blood bank, application owner, privacy officer, and clinical leadership to determine what the account could reach and what it actually did. Use the database’s audit trail and other available records; do not infer access solely from an identity-provider sign-in.

• Identify the affected account’s assigned permissions and role-based access control, including any temporary, elevated, shared, or inherited access.
• Review whether patient transfusion histories were viewed, searched, printed, exported, or changed. Where applicable, assess related records and functions such as test results, product information, orders, release steps, and documented transfusion activity.
• Investigate changes to patient or product data, user permissions, configuration, and audit settings. Determine whether records were altered or deleted, not just whether they were viewed.
• Ask clinical and laboratory leaders to assess whether any potentially affected information must be verified against an authoritative source before it is relied upon for care.
• Determine whether information was acquired or disclosed, to whom, and whether copies may remain in downloads, exports, print queues, or connected services.

Do not ask security responders to make clinical judgments about the validity of transfusion information. Route questions about record integrity and patient-care implications to qualified clinical and transfusion-service leaders, and document their assessment.

How should clinical workflows be protected during the response?

Coordinate containment and investigation with clinical operations so security actions do not create avoidable delays or uncertainty in patient care. Identify an authorized clinical contact who can assess the effect of any account restriction, service isolation, or database unavailability.

• Use the organization’s approved clinical downtime procedures if the database is unavailable, its integrity cannot be trusted, or local policy requires an alternative workflow.
• Follow approved procedures for accessing necessary information during an emergency. HIPAA’s technical safeguards require an emergency access procedure for obtaining necessary ePHI during an emergency; see 45 CFR § 164.312(a)(2)(ii).
• Use only authorized alternatives and approved communication channels. Do not substitute shared credentials, unapproved spreadsheets, or personal messaging for controlled clinical processes.
• Keep a record of actions and decisions made during downtime, and reconcile relevant records back into the designated system when service is restored, following local policy.
• Provide staff with a clear way to report access problems, suspicious prompts, or concerns about record accuracy while the response is underway.

Activate downtime procedures based on the clinical impact and the organization’s escalation criteria—not simply because suspicious prompts occurred if the database remains available and trusted.

What recovery and prevention controls reduce future risk?

Restore normal access only after responders have addressed the suspected entry point, confirmed unauthorized sessions and authentication methods are removed, and relevant system owners have assessed the integrity of affected records. Recheck logging and access controls during recovery, and monitor the account and connected systems for renewed suspicious activity.

• Review role-based access control and remove permissions the user does not need. Confirm that access aligns with current job duties and local policy.
• Where feasible, prefer phishing-resistant MFA. If push-based MFA remains in use, consider number matching and other safeguards supported by the organization’s identity provider. CISA recommends phishing-resistant MFA and identifies number matching as an interim mitigation when that option is not yet available.
• Configure sign-in alerts and review procedures to surface repeated MFA requests, unexpected successful sign-ins, unfamiliar devices, and changes to authentication methods.
• Ensure identity-provider, application, and transfusion database audit logs are available to responders and retained according to organizational policy and applicable requirements.
• Review the incident with staff and update response steps, escalation contacts, and clinical downtime procedures where the findings show a need.
• Have the privacy officer and counsel assess whether an impermissible use or disclosure of protected health information occurred and whether notification obligations apply. HIPAA breach notification depends on the facts and applicable risk assessment; a suspected MFA attack alone does not establish that a reportable breach occurred. See HHS’s Breach Notification Rule guidance.

In summary, treat unexpected MFA prompts as a warning, verify access through logs, contain compromised sessions without losing sight of patient care, and review both record confidentiality and data integrity. Clear coordination between security, privacy, application, and clinical teams supports a safer investigation and recovery.

FAQs

Should staff approve an unexpected MFA prompt?

No. Staff should deny or ignore an unexpected request and report it through the organization’s approved channel. They should not share authentication codes or respond to an unsolicited message or call claiming to be IT. Repeated prompts may signal an MFA fatigue attempt, so responders should assess the account even if the user did not approve one.

How can responders identify a successful sign-in after repeated denied prompts?

Review identity provider sign-in logs for the account across a time window that includes the reported prompts. Check successful and failed outcomes, MFA results, timestamps, source and device details, and session information where available. Correlate those events with the user’s account, endpoint records, and database activity; denied prompts alone do not establish whether a separate sign-in succeeded.

Which transfusion database records and functions should be reviewed?

Review the account’s permissions and available audit history for patient record views and searches, as well as edits, exports, printing, downloads, deletions, or permission changes. Assess associated transfusion-related information and functions that the system contains, such as test results, product records, orders, or documented transfusion events. Ask qualified clinical or transfusion-service leaders to assess the significance of any potentially altered information.

When should clinical downtime procedures be activated?

Follow local escalation criteria when the database is unavailable, its information cannot be trusted, or continued use could create clinical risk. Clinical and transfusion-service leaders should help determine the operational impact. If downtime is activated, use approved alternatives, document activity, and reconcile records according to local policy.