Threat intel

iRhythm, the maker of the Zio heart monitoring patch, has started telling patients that their data was stolen in June. Between June 3 and June 8, 2026, attackers downloaded patient records from what the company calls "certain third-party-hosted business applications". Breach notices filed with state regulators so far cover at least 360,000 people: 298,647 in Texas and 69,526 in South Carolina, with a California notice filed that gives no number. iRhythm has not published a national total, so the real figure is likely higher.

The stolen fields are names, postal and email addresses, phone numbers, dates of birth, iRhythm patient account numbers, device serial numbers, insurance numbers and dates of service. The company says its products, clinical and medical device systems and patient safety were not affected, and that it does not store payment card or bank account details. If your organisation keeps patient contact or billing data in a vendor-hosted app, this is the attack path to check.

Why a June breach is news in October

The breach itself was public in June. iRhythm found the unauthorized activity on June 8, a threat actor contacted it on June 9 claiming to hold proprietary data and patient information and demanding payment to keep it quiet, and on June 10 the company decided the incident was material because of the volume of data involved. That decision triggered a Form 8-K filing with the Securities and Exchange Commission (SEC) under Item 1.05, the rule that makes listed US companies disclose material cyber incidents within four business days.

What is new is who has been told. iRhythm says it finished its forensic investigation and began mailing notices on October 2, to people for whom it holds contact details. The state attorney general filings that produced the 360,000 figure followed, and The Record and SecurityWeek reported them on October 9. That is 116 days between detection and the first letters, nearly four months in which the extortionists held patient data that the patients did not know was gone.

iRhythm has not said whether it paid. It says it has "no evidence that any personal information has been or will be used to commit identity theft", and no extortion group has publicly claimed the attack. Its press release does not mention free credit monitoring; it points people to fraud alerts, credit freezes and free credit reports instead.

How they got in

iRhythm's 8-K says the data "was obtained through social engineering" and came from third-party-hosted business applications. It has not named the application, the vendor or who was tricked, and no reporting adds to that.

The general pattern is well documented, though. In June 2025 Google's Threat Intelligence Group described UNC6040, a group that phoned employees while posing as IT support and talked them into authorising a malicious "connected app" in their company's Salesforce tenant, often a modified copy of Salesforce's own Data Loader. Once a user approves an app like that, it receives an OAuth token (a delegated access grant that works without the user's password or multi-factor prompt) and can export whole tables through the API. Google found no Salesforce vulnerability in any of those cases; the access was granted by a real user. The theft was followed by delayed extortion, sometimes under the ShinyHunters name.

iRhythm has not said its attack worked this way. The model is still useful because it shows why SaaS data theft is hard to spot: the sign-in looks legitimate and the export runs over the vendor's API, so your firewall, endpoint agent and email gateway see nothing.

What a healthcare-adjacent organisation should check

Start with an inventory. List every hosted application that stores patient names, insurance numbers or appointment data: the CRM, the billing and revenue cycle platform, the patient contact centre, the support ticketing tool, the e-signature service. For each, find out who the admins are, whether single sign-on (SSO) is enforced, and how long your plan keeps audit logs. Retention varies by vendor and licence tier, and an intrusion found weeks later can only be traced if the logs still cover its first day.

Then look for the activity a social engineering intrusion leaves behind:

• Exports and API volume. In each app's audit or event log, look for report exports, bulk API queries and data loader jobs, especially from users who never ran them before, outside working hours, or from VPN and Tor exit addresses. In Salesforce, the Setup Audit Trail and, where licensed, Event Monitoring's API and report export events hold this.
• Authorised apps and tokens. List the third-party OAuth apps each user and admin has approved (in Salesforce, Setup > Connected Apps OAuth Usage; in Microsoft Entra ID, Enterprise applications and their user consents). Revoke anything nobody can explain, and restrict new app approvals to admins.
• API keys and service accounts. Long-lived integration keys outlive the people who created them. Rotate them, scope them to the objects they actually need, and restrict them by IP address where the app allows it.
• Vendor and support access: check whether the vendor's support staff can log in to your tenant ("login as" or delegated admin features) and whether that access is time-limited and logged.
• Help desk procedure. The UNC6040 calls went to ordinary users posing as IT support. Require a call-back to a known number before any password reset, MFA re-enrolment or app approval requested by phone.

Write down your notification clocks before you need them. Under the HIPAA Breach Notification Rule, covered entities must notify affected people without unreasonable delay and no later than 60 calendar days after the breach is discovered, and the clock starts when the incident is known, not when the forensic report lands. A business associate's discovery date counts for the covered entity it serves. Texas wants its attorney general notified within 30 days when 250 or more Texans are affected and individuals within 60 days, other states have their own rules, and listed companies have the four-business-day SEC rule on top. Which of these applied to iRhythm, and whether any deadline was extended, has not been reported.

If you received a letter

The leaked fields are enough for convincing phishing: a caller or email that quotes your Zio device serial number, insurance number and date of service will sound like iRhythm or your insurer. Treat any unexpected contact about your heart monitor, a bill or a refund as suspect, and call back on the number printed on your insurance card or the iRhythm notice.

Read every explanation of benefits statement from your insurer and report services you did not receive, since insurance numbers can be used for medical identity fraud. A credit freeze at the three US credit bureaus is free and stops new accounts being opened in your name; with no payment data or Social Security numbers listed among the stolen fields, it is a precaution rather than an urgent step.

The wider lesson

According to iRhythm, the attackers never touched its clinical systems and went to the hosted business applications instead. Those apps are easy to leave out of logging, penetration tests and incident response plans because the vendor runs them, yet the settings that decide who can approve an app, export a report or reset a password in your tenant belong to you.

Our attack surface management work includes the SaaS tenants, connected apps and API keys that sit outside your network, and our security operations team can bring SaaS audit logs into the same monitoring as everything else. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: iRhythm Form 8-K, SEC, iRhythm press release, October 2, 2026, The Record, SecurityWeek, BleepingComputer, HIPAA Journal, Security Affairs, Google Threat Intelligence Group on UNC6040, HHS Breach Notification Rule, Texas Business and Commerce Code 521.053.