SIM Swap Attack Response Guide for a Marrow Pathology Image Archive

A SIM swap can put phone-based account recovery and text-message multifactor authentication at risk. If a suspected swap may have exposed a marrow pathology image archive, treat it as a security incident: verify what happened, contain access, preserve evidence, assess affected information, and determine whether notification is required.

How can you confirm a SIM swap and identify affected accounts?

Start by contacting your mobile carrier through a known, independent channel—not a number or link in an unexpected message. Ask the carrier to confirm whether a SIM or eSIM change, number transfer, port-out request, or account recovery occurred, and when. A sudden loss of cellular service can be a warning sign, but does not by itself prove a SIM swap.

Ask the carrier to secure the subscriber account, restore control of the number, and provide any available records of the change. The FCC describes SIM swapping as transferring a victim’s service to a device controlled by an attacker; port-out fraud instead transfers the number to an account with another carrier. See the FCC’s SIM-swap and port-out fraud order.

From a trusted device and network, review accounts that use the affected number for login verification or recovery. Prioritize the archive’s identity provider, single sign-on, email, remote access, cloud hosting, backup services, and vendor portals. Check for unfamiliar logins, password resets, new devices or authenticators, changed recovery details, and unexpected account lockouts. A carrier takeover can enable multifactor authentication bypass when a service sends recovery codes by text, but does not itself establish that the attacker accessed the archive.

Notify your incident response lead, security team, privacy officer, and archive or hosting vendor according to your response plan. If the repository is managed by a business associate, promptly coordinate with it; HIPAA requires business associates to address security incidents and report them to the covered entity as specified in the applicable business associate agreement. See HHS guidance on cloud service provider security incidents.

How should you contain unauthorized access to the image archive?

Use a trusted administrative account and device to disable or suspend the suspected account, revoke active sessions and refresh tokens, and remove unfamiliar recovery methods, devices, and authenticators. Reset affected passwords from a clean device; change reused passwords on other accounts as well. Revoke suspicious API keys, service tokens, delegated access, and active vendor sessions where the investigation indicates they may be exposed.

Restrict access to the digital pathology image repository while preserving clinically necessary access through verified accounts and approved downtime procedures. Coordinate containment with the archive vendor, identity provider, cloud provider, and security team. Avoid deleting accounts, files, or logs before evidence has been preserved.

Ask the carrier to restore the number and add available protections, such as an account PIN or port-out lock. Until control is confirmed, do not rely on calls or text messages to the affected number to verify the identity of responders or approve account recovery. The CISA Mobile Communications Best Practice Guidance recommends adding a PIN and multifactor authentication to mobile carrier accounts to reduce SIM-swap risk.

Which marrow pathology images and metadata may have been exposed?

Determine what the suspected account could access, not just which files show evidence of a download. Review permissions and activity for whole slide images, thumbnails, scanned slides, case lists, annotations, reports, image exports, and related records. Identify whether the account could view, download, share, edit, or delete these materials.

Check associated metadata and connected systems for patient names, medical record or accession numbers, dates, labels, case identifiers, diagnoses, and links between image files and patient records. An image or metadata field is not automatically protected health information in every context; assess whether the information relates to an individual’s health and identifies them, or could reasonably be used to identify them. HHS describes these elements in its HIPAA de-identification guidance.

For each potentially affected file or record, document the relevant time period, the user or service account, access permissions, and available evidence of viewing, downloading, exporting, sharing, or modification. Include copies or cached versions in connected storage and backups if the account could access them. Distinguish confirmed access from possible access and unknown activity; do not characterize data as unaffected simply because no download event appears in one log source.

How should you preserve logs and other evidence?

Preserve whole slide image access logs and relevant records from the archive, identity provider, single sign-on platform, multifactor authentication service, cloud or storage platform, VPN, email, endpoints, and mobile carrier. Capture authentication attempts, successful and failed logins, session creation, password and recovery changes, device registrations, file views, downloads, exports, shares, permission changes, and administrative actions, as available.

Export logs and related artifacts promptly because retention periods and vendor access vary. Preserve the original exports in access-controlled storage, record who collected them and when, retain timestamps and time-zone information, and make working copies for analysis. Keep incident notes, carrier case numbers, vendor communications, containment actions, and decisions alongside the technical evidence.

Do not alter or delete original evidence while responding. HHS identifies collecting and preserving relevant data, including log files and other artifacts, as part of security incident response; the HIPAA Security Rule also requires procedures to review information system activity, such as audit logs and access reports. See HHS OCR’s cybersecurity incident response guidance and the current eCFR text of 45 CFR § 164.308.

What steps should you take to restore access and strengthen authentication?

Restore access only after the carrier account, affected credentials, and recovery methods are under trusted control. Re-enable users with verified identities and appropriate permissions, and check for unauthorized accounts, forwarding rules, integrations, or access changes. Confirm that the archive and connected services are functioning and that clinical workflows can proceed securely.

Where supported, replace SMS-based authentication with phishing-resistant authentication, such as FIDO/WebAuthn security keys or passkeys, and remove SMS as a fallback where operationally appropriate. NIST identifies SIM changes and number porting as risk indicators for phone-network authentication and recommends considering them before sending an authentication secret through that channel. See the NIST Digital Identity Guidelines for authenticators. This is authentication guidance, not a separate HIPAA mandate to use a specific product or method.

Review account recovery procedures, carrier-account protections, least-privilege access, alerting for new devices and credential changes, and monitoring of unusual archive activity. Update incident procedures based on findings, document the changes, and ensure staff know how to report suspected account takeover. The HIPAA Security Rule calls for safeguards that protect electronic protected health information and procedures to identify, respond to, mitigate, and document security incidents; see the HHS Security Rule overview.

When must you notify affected individuals and regulators?

A SIM swap or suspected account compromise does not automatically mean a reportable HIPAA breach occurred. If there was an impermissible use or disclosure of protected health information, the event is presumed to be a breach unless the covered entity or business associate can demonstrate a low probability that the information was compromised through a documented risk assessment. Consider the information and identifiers involved, who received or used it, whether it was actually acquired or viewed, and how the risk was mitigated. See the HHS HIPAA Breach Notification Rule guidance.

If the incident involves unsecured protected health information and is a reportable breach, covered entities generally must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery. For breaches affecting 500 or more individuals, notice to HHS is due without unreasonable delay and no later than 60 days; for breaches affecting fewer than 500 individuals, the covered entity generally reports to HHS within 60 days after the end of the calendar year in which the breach was discovered. A breach affecting more than 500 residents of a state or jurisdiction also requires notice to prominent media outlets serving that area.

Business associates must notify the covered entity under HIPAA and the applicable business associate agreement; the covered entity remains responsible for ensuring required individual notices are made. Check applicable state breach-notification laws and contractual requirements as well, since they may impose additional or different duties. Document the breach assessment and the basis for either notifying or determining that notification is not required.

In short, confirm the carrier event, contain access, preserve evidence, establish what image and metadata records were exposed, and document the breach assessment. Use those findings to guide restoration, security improvements, and any required notifications.

FAQs

What are the first steps after a suspected SIM swap targeting an image archive?

Contact your carrier through a trusted channel to confirm and secure the number, then use a trusted device to secure email, identity, and archive accounts. Revoke suspicious sessions and recovery methods, alert your incident response and privacy teams, coordinate with vendors, and preserve relevant logs before they expire.

Can attackers access pathology images through a SIM swap alone?

Not necessarily. A SIM swap transfers control of a phone number; access to pathology images depends on whether the attacker can use that number to access or recover an account with archive permissions. Review authentication, account recovery, and archive activity to determine whether access occurred.

Which archive logs should be preserved during incident response?

Preserve authentication and session records, password and recovery changes, device registrations, permission changes, administrative actions, and records of image views, downloads, exports, and sharing. Also retain relevant identity-provider, cloud-storage, endpoint, VPN, vendor, and carrier records, along with incident notes and response timelines.

When may a SIM swap incident require breach notification?

Notification may be required if an impermissible use or disclosure of unsecured protected health information occurred and the organization cannot demonstrate a low probability that the information was compromised through the required risk assessment. Apply the HIPAA rules and any applicable state laws to the specific facts; a suspected SIM swap alone does not establish that a reportable breach occurred.