Token Blog: Phishing and Ransomware Articles

iRhythm’s Breach Was Not a Device Hack. It Was an Identity Failure.

Written by Kevin Surace | Jul 20, 2026 1:00:00 PM

iRhythm Technologies has disclosed a material cybersecurity incident involving patient protected health information, proprietary information, and other personal data held in certain third party hosted business applications. The company says the data was obtained through social engineering. It identified suspicious activity on June 8, received an extortion demand on June 9, and confirmed that data had been exfiltrated. iRhythm has said its clinical systems, medical devices, patient safety operations, manufacturing, and customer connections were not affected.  That distinction matters.

This was apparently not an attack on a cardiac monitor. It was not an attack on a medical device. It was not a sophisticated exploit of clinical infrastructure. It was an attack on a person with access. And that is exactly where far too many healthcare organizations are still vulnerable.

What Most Likely Happened

iRhythm has not publicly identified the affected third party application, the specific vendor, or the exact social engineering technique. So nobody should pretend the forensic conclusion is public. But the likely attack paths are painfully familiar.

An attacker may have called a vendor help desk while impersonating an iRhythm employee, administrator, contractor, or partner. They may have used publicly available information, LinkedIn profiles, an AI generated voice clone, or a convincing internal story to persuade someone to reset a password, share MFA code, enroll a new device, or grant account recovery access.

They may have sent a highly tailored phishing email to a user with access to the third party platform. The employee clicks a convincing login link, enters credentials, completes an authenticator code or push approval, and the attacker relays that authentication in real time into the legitimate application.

Or the attacker may have compromised an administrator account at the vendor itself, then used that access to search, export, and exfiltrate data from the hosted environment. Different details. Same root cause. A system accepted a login because it had a password, a code, a push approval, a recovery process, or a persuasive human on the phone. That is not identity assurance. That is identity guesswork.

Why Third Party Access Is Now the Real Front Door

Healthcare companies often spend enormous sums protecting clinical networks, medical devices, endpoint tools, and patient systems. Then patient data is copied into business applications used by vendors, call centers, analytics firms, HR platforms, customer support tools, cloud collaboration systems, and outsourced operations. Every one of those platforms becomes part of the healthcare organization’s identity perimeter. A third party relationship does not reduce the organization’s responsibility. It expands its attack surface.

The attacker does not care whether the application is operated by iRhythm, a software provider, a business process outsourcing firm, or a cloud vendor. They care about one thing: who has access to sensitive data and how easily can that person be impersonated.

In this case, the attacker reportedly obtained data through social engineering from third party hosted business applications. That means the most important control was never simply antivirus, endpoint detection, or even data encryption. It was knowing with certainty that the person logging in was actually the authorized human.

How Token Would Have Stopped This

Token changes authentication from “someone approved a login” to “the actual authorized person is physically present and biometrically verified.”

With Token biometric assured identity deployed for iRhythm users and any third party administrators with access to iRhythm data, the likely attack paths collapse. There is no password for a help desk agent to reset, no six digit code for an employee to read to a fake support person, no push notification for a tired employee to approve, or authenticator app prompt that can be relayed through a phishing site.

Instead, access requires all of the following:

    • The correct Token device must be present.
    • The enrolled user must provide a live fingerprint match.
    • The authentication request must come from the legitimate registered domain.
    • The device must be physically near the endpoint being used for login.

A criminal calling a vendor help desk cannot talk their way around a fingerprint. A phishing page cannot persuade Token to authenticate to a fake domain. A stolen password is useless. A stolen Token device is useless without the authorized user’s fingerprint. A remote attacker cannot simply relay a push approval from a victim to their own session.

That is the difference between legacy MFA and biometric assured identity. Legacy MFA asks, “Did someone enter the right code?” Token asks, “Is this the actual authorized person, using the actual device, at the actual legitimate application, right now?”

The Uncomfortable Lesson for Healthcare

iRhythm’s clinical systems may have remained protected. That is good. But patients do not care whether their protected health information was exposed through a medical device environment or a third party business platform. Their data is still their data.

Healthcare organizations need to stop treating vendor platforms as someone else’s security problem. Every third party account with access to patient information should be governed by the same phishing resistant identity standard as the most sensitive internal clinical system.

Social engineering works because legacy authentication still gives attackers something to steal, reset, relay, approve, or manipulate.

Token takes those options away. No biometric match. No legitimate domain. No physical presence. No entry.