SmishAlert
← Blog

Disable SMS MFA and Add SMS Telemetry to Stop Healthcare Smishing

Disable SMS MFA and Add SMS Telemetry to Stop Healthcare Smishing

Yes, SMS phishing is an active, high-priority threat to healthcare organizations, and the highest-priority fix is removing SMS as an MFA fallback wherever possible. HHS OCR and CISA both flag SMS-based authentication as exploitable. Enable reporting and telemetry on SMS OTP flows now, because closing that visibility gap, an area platforms exist to address, matters as much as the authentication fix itself.

TL;DR:

  • Removing SMS as an MFA fallback is crucial, and organizations should disable SMS-based authentication for high-risk accounts to reduce exploitability.
  • Enterprises must implement telemetry on SMS OTP flows, monitoring for abnormal resend rates, international attempts, and automated sign-up patterns, to detect ongoing attacks.
  • Technical safeguards like migrating to phishing-resistant passkeys and rate-limiting OTP requests are essential to prevent credential theft and toll-fraud.
  • Bridging the SMS visibility gap requires integrating user reports with automated analysis and correlation to identify coordinated smishing campaigns quickly.
  • Enforcing verified out-of-band confirmation policies and providing patient verification channels can help mitigate social engineering risks and improve response effectiveness.
SmishAlert
Close the SMS Visibility Gap
SmishAlert helps security teams collect, analyze, and correlate suspicious messages to identify coordinated social engineering campaigns.
  • ✓Collect suspicious messages
  • ✓Analyze threats and senders
  • ✓Correlate reports across users
  • ✓Identify coordinated campaigns
Explore SmishAlert

Table of Contents

What smishing is and why healthcare is a prime target

Smishing is phishing delivered by text message rather than email, and it exploits a channel people trust more instinctively than their inbox. Recipients rarely inspect sender numbers the way they scrutinize email headers, and mobile screens compress URLs and sender names, hiding the cues that would raise suspicion on a desktop. Caller ID and SMS sender fields can also be spoofed, letting attackers impersonate a hospital’s own short code or a known vendor.

Healthcare compounds the risk because a single compromised credential can open a path to electronic protected health information (ePHI), scheduling systems, and prescription workflows. HHS OCR’s October 2024 newsletter identifies smishing as a primary social engineering vector used to harvest credentials, install malware, and bypass multi-factor authentication.

The downstream consequences typically include:

  • Credential theft that can lead to unauthorized EHR or patient portal access
  • Financial losses to patients resulting from impersonation scams
  • Increased telecom costs resulting from abuse of OTP and toll-fraud linked to account sign-up flows

How attackers target healthcare: campaign types and examples

Healthcare-specific smishing campaigns tend to follow recognizable patterns rather than random spam:

  1. Executive or help-desk impersonation, where an attacker poses as IT support or a hospital executive requesting urgent credential resets.
  2. Insurer or law enforcement impersonation, a pattern the FBI has documented, where criminals pose as fraud investigators or benefits administrators to extract payments or PHI.
  3. Credibility building with harvested PII, using data from prior breaches to reference real claim numbers or appointment details before making demands.
  4. Urgent payment requests, often steering victims toward prepaid cards or cryptocurrency, paired with threatening or time-pressured language.
  5. Secondary-platform transitions and OTP abuse, where a conversation moves from SMS to a messaging app or triggers repeated one-time-passcode sends to monetize telecom traffic.

Closing the visibility gap: what telemetry to collect

Most enterprise security stacks were built around email. Gateways inspect attachments, sandbox links, and quarantine suspicious senders, but none of that coverage extends to a text message landing on an employee’s or patient’s phone. That gap is precisely where smishing operates undetected until a credential is already compromised or an OTP has already been abused.

Closing it starts with new signals, not new tools alone:

  • Spikes in OTP send volume or resend rates tied to a single account or IP range
  • Enrollment attempts from unusual destination country codes
  • Repeated low-completion sign-up flows suggesting automated abuse
  • User-reported messages that can be correlated across accounts to reveal coordinated campaigns

Ingesting user-reported smishing into a centralized workflow, correlating it across the employee or patient population, and forwarding resulting indicators to SIEM or SOAR tooling turns scattered complaints into actionable detection. The Health-ISAC threat bulletin on OTP and toll fraud documents exactly this kind of abuse against patient portal sign-up flows.

Pro Tip: Route SMS-reported phishing into the same triage queue as email-reported phishing so analysts see one correlated threat picture instead of two disconnected ones.

Technical mitigations: authentication, OTP, and telecom controls

Authentication changes deliver the largest risk reduction. CISA’s 2025 phishing guidance recommends migrating to FIDO-based, phishing-resistant authentication because SMS-delivered codes can be intercepted or socially engineered away from the legitimate user. Migrating primary authentication is not enough on its own: recovery and account-reset flows often quietly reintroduce SMS as a fallback, and that fallback path stays exploitable even after passkeys are deployed elsewhere.

Priority actions include:

  • Migrate high-risk accounts to FIDO or passkey authentication and disable SMS as a fallback path
  • Audit every recovery and reset flow specifically for SMS re-entry points
  • Rate-limit OTP requests, enforce resend cooldowns, and block premium-rate or high-risk international destinations
  • Apply CAPTCHAs, device fingerprinting, and IP reputation checks at enrollment
  • Monitor SMS spend for anomalies and negotiate destination-filtering terms with telecom providers

The Health-ISAC bulletin documents attackers mass-creating accounts and triggering resends toward premium-rate or international numbers to monetize SMS and call traffic, which makes rate limiting and destination controls a direct financial defense, not just a security one. Toll-fraud defenses also require cross-team ownership between security, finance, and product teams, since telecom spend and OTP thresholds rarely sit under one budget owner.

People, policy, and patient outreach that scale

Technical controls only go so far when the attack targets judgment rather than infrastructure. A verified communication policy requiring out-of-band confirmation for any urgent financial or credential request closes the gap that impersonation exploits, and it works best when staff have a documented, fast channel to confirm requests without feeling like they are slowing down patient care.

Effective programs typically include:

  • Role-based smishing simulations that reflect actual job functions rather than generic templates
  • Clear consequences for repeated simulation failures, ranging from targeted retraining to temporary access restriction
  • Verified callback numbers published internally so staff never need to trust a number inside a suspicious text

Patients need parallel options. Call-to-verify lines, branded voice agents, and printed verification cards distributed during visits give patients without smartphones or app access a way to confirm legitimacy, an approach that research on inclusive verification systems has shown can raise attacker costs while remaining usable across a mixed patient population.

Incident response and reporting: a compact runbook

When a smishing incident is confirmed, speed and evidence preservation both matter for containment and for any later regulatory review.

  1. Revoke active sessions tied to the compromised account and force a credential reset.
  2. Block the sending number or route at the carrier or gateway level where possible.
  3. Preserve message text, timestamps, carrier metadata, OTP logs, and enrollment or IP traces before they age out of retention windows.
  4. Report externally as appropriate: CISA for infrastructure-level threats, the FBI’s IC3 for fraud-driven campaigns, Health-ISAC for sector-wide sharing, and HHS OCR when PHI is reasonably believed to be breached.

Pro Tip: Draft the OCR notification checklist before an incident happens. Reconstructing a breach timeline under deadline pressure is far harder than confirming one against a pre-built template.

A smishing attack that results in unauthorized ePHI access triggers the same HIPAA obligations as any other breach vector. Covered entities and business associates must assess whether PHI was accessed or disclosed, and if a breach is confirmed, follow the HIPAA Breach Notification Rule’s timelines for notifying affected individuals, HHS, and in larger cases, the media.

HHS OCR guidance makes clear that social engineering incidents fall squarely within the Security Rule’s expectations for workforce training and access management, not just technical safeguards. That means an organization cannot treat a smishing incident as purely a phone carrier problem or an individual employee’s mistake. Regulators expect documented training, verified communication protocols, and role-based access controls that limit what a single compromised credential can reach.

The Security Rule’s risk analysis requirement extends to mobile messaging as an attack surface, even though SMS itself is not a covered transmission channel in the way EHR systems are. If a smishing message leads to unauthorized access of a system containing ePHI, the resulting exposure is evaluated the same way a network intrusion would be: scope of access, duration, and the sensitivity of records involved all factor into whether notification is required. Organizations that can demonstrate a documented verification policy and phishing-resistant authentication are generally in a stronger position during any subsequent OCR review, since those controls speak directly to the “reasonable and appropriate” safeguard standard the Security Rule applies.

Legal and regulatory implications for HIPAA compliance — overview diagram

Case studies: what recent healthcare smishing incidents show

Recent federal alerts describe a consistent pattern rather than isolated incidents. The FBI’s 2025 alert on health insurer impersonation documents criminals posing as legitimate insurers and fraud investigators, using spoofed numbers and urgent, threatening language to pressure patients and staff into payments through prepaid cards or cryptocurrency. These campaigns frequently reference real claim numbers or provider names harvested from prior data exposures, which is what makes them convincing enough to bypass ordinary skepticism.

Separately, the Health-ISAC bulletin on OTP and toll fraud documents attackers abusing patient portal account sign-up flows to trigger mass OTP resends toward premium-rate and international numbers, generating telecom costs for the organizations whose portals were exploited. The impact in these cases lands on two fronts at once: direct financial cost from inflated telecom bills and reputational damage when patients associate the abuse with the portal itself, even though the organization did not initiate the fraudulent traffic. Both patterns point to the same underlying weakness: verification and monitoring gaps that exist specifically because SMS traffic sits outside the visibility most security teams have built around email.

SmishAlert: closing the SMS visibility gap for healthcare organizations

Every mitigation described above depends on one capability healthcare security teams often lack: a way to see what is actually landing on employee and patient phones. SmishAlert enhances security teams’ visibility by integrating user reporting with automated threat analysis, transforming suspicious texts into triaged, correlated data points for actionable insight.

The platform supports:

  • Frictionless reporting for employees and high-risk users, plus customer and patient reporting that does not require an app install
  • Automated analysis of reported messages and senders for credential phishing, executive impersonation, and payment scams
  • Cross-user correlation that surfaces coordinated campaigns rather than isolated complaints
  • SIEM and API integration so smishing indicators feed the same workflows as other threat intelligence

Deployment does not require replacing existing MDM or email security investments. Organizations typically start with a scoped pilot, map the resulting alerts into existing SOC playbooks, and use the threat intelligence to tune OTP rate limits and destination controls described earlier in this guide. For security teams evaluating how to close the mobile visibility gap without a long procurement cycle, SmishAlert’s product overview outlines the detection and reporting architecture in more detail, and the enterprise page is the starting point for scoping a pilot.

Sources

FAQ

Why am I getting calls that say healthcare?

Calls or texts claiming to be from a healthcare provider or insurer are frequently impersonation attempts designed to extract payment or personal information. The FBI has warned that criminals pose as legitimate insurers and fraud investigators using spoofed caller ID to appear credible.

Can I get a phishing attack through SMS?

Yes, this is called smishing, and it is a documented threat vector that HHS OCR identifies as a primary method for credential theft and malware delivery. It works because people generally trust text messages more readily than email.

How to check if SMS is real or fake?

Verify any urgent request through a separately known contact channel, such as calling a number you already have on file rather than one provided in the text. Legitimate healthcare organizations rarely demand immediate payment or credentials exclusively through text message.

Can you give me an example of a phishing SMS?

A common example impersonates a health insurer or fraud investigator, referencing a real claim number and demanding urgent payment through a prepaid card or cryptocurrency, a pattern documented by the FBI. Another pattern impersonates internal IT support requesting a credential reset through a spoofed link.