iRhythm Data Breach: 8.2 Million Patients and the SaaS Identity Gap

Cardiac monitoring company iRhythm, maker of Zio heart monitors, began notifying patients on 2 October 2026 that unauthorized individuals used social engineering to reach certain third-party-hosted business applications and downloaded data between 3 and 8 June. A filing with the Oregon Attorney General lists 8,179,772 people. No devices were affected. Any team holding patient data in SaaS can act now.

There is no CVE in this story, no vulnerable library and no patch to install. What the public record describes is a person being persuaded to open a door, followed by a large download from business software that someone else hosts. That makes it one of the clearest 2026 examples of a pattern that every healthcare organisation, and every company that keeps customer data in cloud business applications, has to plan for: the identity that unlocks a SaaS tenant is the perimeter, and the help desk, the reset flow and the export button are all part of it.

This post sets out what iRhythm's filings and notice say, what state filings add and what is still unknown. It then covers HIPAA breach notification duties and the identity, help desk verification and export monitoring controls that make a talked out credential far less useful. We make no claims about what iRhythm had in place.

What happened

According to iRhythm's Form 8-K, the company identified unauthorized activity on 8 June 2026 involving data held in certain business applications hosted by a third party. The next day, 9 June, it received communications from a threat actor claiming to have obtained sensitive information, including proprietary data, patient protected health information and other personal information. The actor demanded payment in exchange for not publishing it. The 8-K states that the data "was obtained through social engineering" and gives no further detail about the method.

On 10 June, iRhythm determined the incident was material because of the volume of potentially affected data, while also stating that, based on what it knew then, the incident was not reasonably likely to have a material impact on its financial condition or results of operations. That distinction matters for readers who follow SEC Item 1.05 filings: the materiality call was about the volume of data, not the expected financial effect.

On 2 October, iRhythm published an update. The forensic investigation was complete. The company said it had learned that certain data it stores was accessed and downloaded by unauthorized individuals between 3 and 8 June 2026, and that it had begun notifying affected individuals for whom it maintains contact information. Four days later, on 6 October, iRhythm's notice appeared with the Oregon Department of Justice, listing 8,179,772 affected individuals in total, and with the California Attorney General.

Timeline

No source we read publishes times to the minute or the hour. Every entry below is a calendar date, attributed to the source that states it.

The gaps between those dates

Three intervals stand out, and each one carries a lesson for planning rather than a judgement about iRhythm.

Dwell to detection: about five days. Access started on 3 June and was identified on 8 June. For a SaaS tenant, five days is enough to pull everything an account can read. Whatever alerting a team has on bulk export needs to fire in hours, not days.

Detection to extortion: one day. The actor made contact on 9 June. That is a common shape for data theft extortion: the first time the victim hears from the attacker, the data is already gone. Restore from backup does nothing for this kind of incident, which is why prevention and early detection on the export path matter so much.

Detection to individual notice: 116 days. From 8 June to 2 October is 116 days. Large investigations take time, particularly when a team must work out which records belong to which person and where each person lives. The HIPAA rule sets an outer limit on that time, which we cover below. The public record does not explain how the timing in this case was determined, and we do not speculate about it.

Technical details

This incident has no CVE, no affected software versions, no file hashes and no network indicators in any primary source. iRhythm has not named the SaaS platform or the method of social engineering, and no primary source names the attacker. Below are the concrete values that the filings and the notice do publish.

Affected systems and status

Data elements in the patient notice

iRhythm's Notice of Data Event lists the following, and states that the data includes protected health information as defined under HIPAA:

The 8-K, written before the review was finished, describes the actor's claim more broadly as proprietary data, patient protected health information and other personal information. The October notice is the later and more specific statement about patient data. One security blog we saw in search results claimed Social Security numbers were involved; that contradicts the notice, and we treat it as unreliable.

Counts reported to regulators

The Oregon row also carries a placeholder breach date of 1/1/0001 next to the real window, which appears to be a data entry artefact rather than a fact about the incident. iRhythm itself has not published a national total; as noted above, it pointed BankInfoSecurity to its regulatory filings. The 8,179,772 figure should therefore be quoted as what the Oregon filing lists, not as an iRhythm announcement.

Contact values from the notice

Litigation and disclosure posture

iRhythm's 10-Q for the quarter ended 30 June reports three putative class action lawsuits filed in June in the US District Court for the Northern District of California, San Francisco Division. Two name iRhythm Holdings, Inc. and one names iRhythm Technologies, Inc. All three were assigned to the same judge, and the company expects consolidation. The 10-Q says the outcome is uncertain and does not quantify incident costs. The 8-K notes cybersecurity insurance that may cover some losses, without assurance of full coverage.

How social engineering reaches a SaaS tenant

iRhythm has not said how the social engineering worked, so this section describes the general pattern in plain terms, without exploit detail, and does not suggest it is what happened here.

Business applications hosted by a vendor are reached through an identity. Usually that is a single sign on account at an identity provider, sometimes a local account inside the SaaS application, and sometimes a token held by an integration. Social engineering aims at whichever of those is easiest to talk someone into handing over. The common variants that defenders plan for are:

1. Help desk impersonation. A caller poses as an employee who is locked out and asks for a password reset or for multifactor enrolment to be cleared. If the help desk resets on the strength of a convincing story, the caller now owns the account.
2. Employee impersonation of IT. The reverse: a caller poses as IT support and talks an employee into approving a prompt, reading out a code or visiting a sign in page that relays credentials.
3. Consent and integration abuse. A user is persuaded to authorise an application or connector that then holds a long lived token with broad read access to the tenant.

All three end in the same place. A legitimate session or token with legitimate permissions is used to read and download data. No exploit fires, and nothing in the SaaS platform is broken. That is why the controls that matter are about who can obtain a credential, what that credential can reach, and how fast an unusual export is noticed.

Why this is a third-party risk story

The data sat in applications that another company hosts. That changes the defence in two ways. First, the customer controls the identity, the permissions, the integrations and the configuration, while the vendor controls the platform, its logs and what monitoring features exist. Second, the evidence a customer needs after an incident often lives in the vendor's logs, under the vendor's retention rules. A third-party risk programme that asks only "is the vendor secure" misses the half of the risk that sits in how the customer's own tenant is set up. We made a related point about hosting providers in our IDCF Cloud ransomware post.

Who is affected

If you are a patient

The notice recommends watching for medical identity theft (read every explanation of benefits statement, question services you did not receive, and ask your insurer for a year to date report of paid services), considering a free one year fraud alert or a free security freeze with Equifax, Experian or TransUnion, and checking your free annual credit reports. If you find misuse, file a police report and report to the FTC. Expect phishing that quotes real details such as your device serial or insurer, and call back on a number you look up yourself before acting on any message about this incident.

HIPAA breach notification: what the rule requires

The notice states that the data includes protected health information under HIPAA. Whatever the specifics of this case, any team that holds PHI should know the federal breach notification rule in 45 CFR Part 164, Subpart D, by heart before it ever needs it. The summary below uses the regulation's own structure.

When an incident is a breach

Under 45 CFR 164.402, a breach is the acquisition, access, use or disclosure of PHI in a way the Privacy Rule does not permit. It is presumed to be a breach unless the covered entity or business associate shows "a low probability that the protected health information has been compromised," based on a risk assessment of at least four factors:

1. The nature and extent of the PHI, including the identifiers and how easily people could be re-identified.
2. The unauthorized person who used the PHI or received it.
3. Whether the PHI was actually acquired or viewed.
4. How far the risk to the PHI has been mitigated.

A confirmed download by an extortionist leaves little room on factors two and three. Plan on the presumption holding.

Notice to individuals

Under 45 CFR 164.404, notice is due without unreasonable delay and "in no case later than 60 calendar days after discovery." Discovery is the first day the breach is known to the organisation, or would have been known with reasonable diligence, and knowledge of any workforce member or agent other than the person who committed the breach counts. The 60 days is an outer limit, not a target.

The notice must be in plain language and include, to the extent possible:

Written notice goes by first class mail to the last known address, or by email if the person agreed to electronic notice. When contact information is out of date for 10 or more people, substitute notice is required: a conspicuous web posting for 90 days or notice in major print or broadcast media where those people likely live, plus a toll free number active for at least 90 days.

Notice to the media and to HHS

Under 45 CFR 164.406, a breach affecting "more than 500 residents of a State or jurisdiction" also requires notice to prominent media outlets serving that area, on the same 60 day outer limit. Under 45 CFR 164.408, breaches affecting 500 or more people must be reported to HHS "contemporaneously" with the individual notice, in the manner HHS specifies on its website. Smaller breaches go into a log reported within 60 days after the end of the calendar year. HHS posts reports of 500 or more on the OCR breach portal, which is why the portal is the place most journalists check first, and why a gap between state filings and a portal listing tends to draw questions. HIPAA Journal reported that this incident was not on the portal as of 19 October; we could not confirm a listing either way when we checked the portal's landing page.

Business associates and law enforcement delays

If a business associate discovers a breach, 45 CFR 164.410 requires it to tell the covered entity within the same 60 day outer limit and to identify, as far as possible, each affected person. That clause is where SaaS contracts and BAAs matter: if your vendor sees an unusual export first, your clock depends on how fast it tells you.

Under 45 CFR 164.412, notice must be delayed if a law enforcement official states that it would impede a criminal investigation or damage national security. A written statement sets its own period. An oral statement must be documented and allows a delay of no more than 30 days unless a written statement follows.

How this applies to planning, not blame

The 116 days between discovery and notice in this case are a matter of public record, and the public record does not say whether any law enforcement delay applied, how iRhythm's HIPAA role applies to each patient population, or how state law deadlines were handled. We draw no conclusion. The practical lesson for any team is that the 60 day outer limit begins at discovery, not at the end of the forensic review, so the work that usually takes longest (mapping exported records to people and addresses) needs to be possible quickly. That depends on knowing, before an incident, exactly which PHI fields live in which SaaS application.

State laws add their own clocks and content rules. iRhythm's notice includes separate sections for residents of Connecticut, Iowa, Maryland, Massachusetts, New Mexico, New York, North Carolina, Oregon, Rhode Island, Washington D.C. and West Virginia, and Oregon requires a report to its DOJ when more than 250 Oregon consumers are affected. A notification plan has to cover every one of those, in parallel with HHS.

What to do now in your SaaS estate

These steps apply to any organisation that keeps PHI or customer data in third-party-hosted business applications. We use widely deployed identity tools for concrete commands. Adapt the event names to your own platform, and check each vendor's documentation for your edition and licence.

1. Make a list of every SaaS application that holds PHI

Start with the inventory, because every later step depends on it. For each application record the PHI fields it holds, the number of records, who administers it, how users sign in, what integrations hold tokens, what audit logs the vendor provides and for how long, and whether a BAA is in place.

A minimal register can live in a spreadsheet or a JSON file. Here is a starting shape:

{
  "app": "crm-production",
  "vendor_hosted": true,
  "phi_fields": ["name", "address", "dob", "insurance_number", "date_of_service"],
  "approx_records": 8000000,
  "sso_enforced": true,
  "local_accounts": ["break-glass-admin"],
  "integrations_with_tokens": ["support-desk-sync", "marketing-export"],
  "audit_log_retention_days": 180,
  "baa_signed": true,
  "owner": "patient-ops"
}

If you cannot fill phi_fields and approx_records for an application today, that is the first gap to close, because it is the same question you would have to answer under the 60 day clock.

2. Require phishing resistant sign in for the accounts that can export

CISA's fact sheet on phishing resistant MFA ranks FIDO/WebAuthn and PKI based methods as the strongest form, places app based push and one time codes below them as vulnerable to phishing, and calls SMS or voice codes a last resort. CISA "strongly urges" administrators and other high value targets to move to phishing resistant methods. NIST SP 800-63B-4 defines phishing resistance as a property of the protocol that does not depend on the user's vigilance, requires it at AAL3 and requires verifiers to offer it at AAL2.

Start with the people who matter most in a SaaS data theft: tenant administrators, anyone with report or export permissions, integration owners, and the help desk staff who can reset others.

If Microsoft Entra ID is your single sign on front door, you can list users and their registered methods to find export capable accounts that still rely on phishable methods:

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","User.Read.All"
$group = Get-MgGroup -Filter "displayName eq 'SaaS-Exporters'"
Get-MgGroupMember -GroupId $group.Id -All | ForEach-Object {
  $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
  [pscustomobject]@{
    User    = $_.Id
    Methods = ($methods.AdditionalProperties.'@odata.type' -join ', ')
  }
}

Any user whose list shows only password, phone or software OTP methods is a candidate for a passkey or FIDO2 key first.

3. Give the help desk a verification step a voice cannot fake

NIST SP 800-63B-4 is direct about the design principle: recovery is a defined process with specific methods (saved recovery codes, issued recovery codes, recovery contacts, or repeated identity proofing), and an account recovery or new authenticator binding must trigger a notification to the subscriber with instructions in case they did not perform it. The document also warns against authenticators that create social engineering risk for customer service agents.

Turn that into a runbook:

1. No reset on a call alone. The agent ends the call and calls back on a number from the HR system, never on the number the caller gives.
2. Verify with something the caller holds. Vendor tools exist for this. Microsoft's documentation, for example, describes a help desk requesting a Face Check against a VerifiedEmployee credential before activating a passkey or resetting a password, with the requesting app receiving only a match confidence score. The default threshold is 70 on a scale of 50 to 100, and the documentation says a 50 percent threshold corresponds to a one in 100,000 chance that the person is not the credential owner.
3. Issue a short lived, single use recovery credential, not a reusable password, and require the user to enrol a phishing resistant method with it.
4. Notify the user through a second channel when a reset or enrolment happens, as NIST requires.
5. Escalate privileged resets. Administrator and export capable accounts need a second approver.
6. Log every reset with a ticket number, so you can match resets to tickets later.

4. Hunt for resets and new methods you cannot explain

Match identity events to help desk tickets. In Microsoft Entra ID, directory audit records cover admin password resets and security info registration:

Connect-MgGraph -Scopes "AuditLog.Read.All"
$since = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogDirectoryAudit -All -Filter "activityDateTime ge $since and activityDisplayName eq 'Reset password (by admin)'" |
  Select-Object ActivityDateTime, @{n='Target';e={$_.TargetResources[0].UserPrincipalName}}, @{n='By';e={$_.InitiatedBy.User.UserPrincipalName}}
Get-MgAuditLogDirectoryAudit -All -Filter "activityDateTime ge $since and activityDisplayName eq 'User registered security info'" |
  Select-Object ActivityDateTime, @{n='Target';e={$_.TargetResources[0].UserPrincipalName}}

If Okta is your identity provider, the System Log API answers the same question:

curl -s -H "Authorization: SSWS $OKTA_API_TOKEN" \
  "https://$OKTA_DOMAIN/api/v1/logs?since=2026-09-23T00:00:00Z&filter=eventType%20eq%20%22user.mfa.factor.reset_all%22" \
  | jq -r '.[] | [.published, .actor.alternateId, (.target[0].alternateId // "")] | @tsv'

Repeat with user.mfa.factor.deactivate and user.account.reset_password. Every row without a matching ticket is worth a phone call to the user, on a number you already hold.

5. Review integrations and consent grants

Long lived tokens held by connected applications are the quietest path to a full export. Review every integration with read access to PHI, remove what nobody owns, and narrow scopes on the rest. In Entra ID, delegated consent grants can be listed like this:

Connect-MgGraph -Scopes "Directory.Read.All"
Get-MgOauth2PermissionGrant -All |
  Select-Object ClientId, ConsentType, PrincipalId, ResourceId, Scope |
  Sort-Object ConsentType

Grants with ConsentType of AllPrincipals apply to every user in the tenant. Look up each ClientId with Get-MgServicePrincipal -ServicePrincipalId <id> and confirm someone owns it. Most SaaS platforms have an equivalent page listing connected apps and API clients; review it on the same schedule.

6. Watch the export path, not just the login

Every SaaS platform that holds PHI has some way to pull data out in bulk: report exports, list downloads, API queries, data loader tools, backups. Find out which events your vendor logs for each, at which licence tier, and for how long. Then alert on volume.

HIPAA's Security Rule already asks for this in general terms. 45 CFR 164.312(b) requires mechanisms that "record and examine activity in information systems" containing ePHI, and 164.308(a)(1)(ii)(D) requires procedures to "regularly review records of information system activity." The practical version is a baseline per user and an alert when someone exceeds it.

If your platform can export its audit events as JSON lines, a first pass needs nothing more than jq. This assumes each line has user, action, records and an ISO timestamp; rename fields to match your vendor's schema:

jq -r 'select(.action | test("export|report_download|bulk_query"; "i"))
       | [.user, (.timestamp[0:13]), (.records // 1)] | @tsv' audit.jsonl \
  | awk -F'\t' '{k=$1"\t"$2; s[k]+=$3} END {for (k in s) if (s[k] > 50000) print k"\t"s[k]}' \
  | sort -t$'\t' -k3 -nr

That prints any user and hour where exported records passed 50,000. Tune the threshold to your own baseline, then move the logic into your SIEM so it runs continuously. The lesson from the dates in this incident is that the alert has to reach someone who can suspend the account within the same working day.

7. Limit what a single account can reach

Even a perfect help desk will one day be fooled. Plan for it:

• Data minimisation. Ask whether every PHI field in each business application is needed there. Insurance numbers and dates of birth often arrive in general purpose tools because a sync copies everything.
• Least privilege on export. Separate the permission to view a record from the permission to export a list of them. Few roles need the second.
• Network and session limits. Where the platform supports it, restrict administrative and export access to managed devices or known address ranges, and shorten idle session timeouts. HIPAA lists automatic logoff in 164.312(a)(2)(iii) as an addressable specification.
• Separate break glass accounts that are excluded from normal reset flows, stored offline and monitored.

8. Contain fast when it happens

Rehearse the sequence before you need it:

1. Suspend the account at the identity provider and revoke its sessions and refresh tokens.
2. Revoke tokens for any integration the account created or authorised.
3. Export the vendor's audit logs immediately, before retention expires, and preserve them.
4. Open a case with the SaaS vendor and ask what platform side logs they hold beyond what you can see.
5. Start the HIPAA four factor assessment and the state law analysis the same day, because the 60 day outer limit runs from discovery.
6. If you are a business associate, notify the covered entity under 164.410.

9. Put SaaS logging and notice duties into the contract

Vendor reviews tend to focus on the vendor's own certifications. For PHI in SaaS, also ask: which audit events are logged at our tier, how long they are kept, whether exports by API are logged, how fast the vendor will tell us about anomalies it sees on our tenant, and whether the BAA covers that timing. Under 164.308(b)(1), a covered entity may let a business associate handle ePHI only with satisfactory assurances of safeguards. Make those assurances specific.

What changed since first reports

Sources also disagree on the 8-K date. The EDGAR document is named for 10 June, the materiality date. It was signed on 15 June, which is the date iRhythm's own October release uses. HIPAA Journal reports the disclosure on 18 June. We use "the June 2026 Form 8-K" and give the event dates from its text.

Open questions

• Which platform and which method? iRhythm has not named the third-party-hosted applications or described the social engineering. No primary source names the attacker.
• What is the national total? The 8,179,772 figure is the Oregon filing's total. iRhythm has not published a number of its own.
• HHS listing. As of 19 October the incident was reported as absent from the OCR breach portal. Whether and when it appears is open.
• Was a payment made? The filings do not say.
• Has data been published? No primary source says the data has appeared publicly.
• What proprietary data was involved? The 8-K mentions proprietary data; the October documents focus on patient data.
• What changed afterwards? iRhythm says it regularly evaluates and modifies its controls, without specifics.

What would have helped

Nothing here claims to know what iRhythm had in place. These are controls that make a social engineering success less damaging in any SaaS tenant that holds PHI.

Practices any team can use

Steps 1 to 9 above are the list: phishing resistant sign in for every account that can export, a help desk that never resets on a call alone, alerts on resets without tickets, owned and narrow integrations, volume alerts on the export path, data minimisation, audit logs kept long enough to finish a review, a HIPAA plan that starts at discovery, and contracts that name SaaS logging and anomaly notice duties.

For a general response template, see our compromised dependency playbook. For a companion case on the same pattern in Microsoft 365, see our CSX vishing breach post. For the month's wider picture, see October 2026 security incidents and what would have helped.

Where Safeguard fits

The boundary first, plainly. Safeguard's fit with this incident is indirect. Safeguard does not monitor sign ins to third-party SaaS applications, does not screen help desk calls, does not watch report exports inside a vendor's platform, and would not have detected or stopped a social engineering call. The controls above live in your identity provider, your SaaS tenants, your help desk and your contracts.

Where Safeguard can help is around that core:

• Third-party risk management. Safeguard's Third-Party Risk Manager (GA) keeps a vendor directory with contracts, SLAs and risk tiers, scores supplier risk and sends monitoring alerts. It is built around the software suppliers ship you, so it will not see a SaaS tenant's sign ins, but it gives the vendor review in step 9 a home: which vendors hold PHI, what was promised, and when each was last reviewed.
• Compliance evidence for HIPAA controls. Safeguard's Compliance suite (GA) maps controls and evidence to frameworks including the HIPAA Security Rule, with tabs for Controls, Evidence, Monitoring, Tests, Policies, Risks and Vendors, and connectors that collect evidence from cloud and identity providers. A help desk verification runbook, a quarterly integration review and an export alert test are exactly the controls that drift without an owner. Recording them as controls with evidence makes drift visible before an auditor or an attacker finds it.
• The software side of the same estate. The integrations that sync PHI into business applications are code. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, results as JSON under ./output), shows which projects contain a given component and version, and evaluates policies and gates in the platform.
• A person on every action. The Safeguard CLI's assistant asks before it edits files or runs commands in its default modes (/permissions offers Ask, Accept edits, Plan, Auto and Strict), and the desktop and phone apps send work to a computer running the CLI where each command is approved or denied. That is the same principle as the help desk rule above: a request is not an approval.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, across seven package ecosystems.

Gold Open Source (gold.safeguard.sh) is free and needs no login, with searchable CVE intelligence including CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

Neither applies to this incident, which involved no software vulnerability. They are relevant to the code and images in the rest of your estate, where the same habit applies: trust what you can verify, not what merely arrives.

Common mistakes

• Treating SaaS as the vendor's problem. The vendor runs the platform. You run the identities, permissions, integrations and export settings, which is where social engineering lands.
• Allowing resets on a convincing story. A caller who knows a name, a manager and an employee ID has done research, not proved identity.
• Logging logins but not exports. Many incidents are visible only in report, list and API events. Check that your tier logs them.
• Starting the HIPAA clock at the end of forensics. The rule counts from discovery.
• Not knowing which fields live where. Mapping records to people under deadline is far slower when the PHI inventory is built during the incident.
• Assuming the threat ended with containment. Exposed patients face months of targeted phishing that quotes real details. Plan patient communications for that.

FAQ

What happened in the iRhythm data breach?

According to iRhythm, unauthorized individuals used social engineering to access certain third-party-hosted business applications and downloaded stored data between 3 and 8 June 2026. A threat actor demanded payment on 9 June not to publish it. iRhythm began notifying patients on 2 October.

How many people were affected?

A filing with the Oregon Attorney General lists 8,179,772 individuals. iRhythm has not published its own national total and says the number is reflected in its regulatory filings. Texas (298,647) and South Carolina (69,526) filings were the basis of earlier, smaller estimates.

What data was exposed?

Patient name, address, email, phone, iRhythm patient account number, device serial number, insurance number, date of service and date of birth, according to iRhythm's notice. iRhythm says it does not store financial account or payment card data, and the notice does not list Social Security numbers.

Were Zio monitors or clinical systems affected?

No. iRhythm says it has identified no impact on its products, clinical or medical device systems, connections to customers, manufacturing, patient safety or its ability to meet patient needs.

Which SaaS platform was involved, and who was behind it?

Neither is public. iRhythm describes only certain third-party-hosted business applications and an unnamed threat actor. We do not name a platform or a group because no primary source does.

How long does HIPAA allow before patients must be told?

Without unreasonable delay and no later than 60 calendar days after discovery, unless a law enforcement official requests a delay under 45 CFR 164.412. Breaches affecting more than 500 residents of a state also require media notice.

Would MFA alone have stopped this?

We do not know what iRhythm used. In general, phishable MFA (codes, push approvals) can be defeated by a persuasive caller or a relayed sign in page, and any MFA can be undone by a help desk reset. Phishing resistant methods plus strict reset verification close both gaps.

What is the single most useful change for a team with PHI in SaaS?

Make every account that can bulk export from a PHI holding application use a phishing resistant method, and make sure no help desk agent can reset that account on a phone call alone.

Fix it without waiting for upstream

This incident had nothing to patch. Most identity driven breaches still lead teams back to the integrations, sync jobs and services they build around SaaS data, and that code and its dependencies are where the fix is yours to ship. The section below covers that side of your estate.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows this incident, a SaaS platform or a help desk call. Each shows a real Safeguard flow built on the principle this incident tests: a request is not an approval, and access is granted on purpose.

The first demo is a real Android session. Work is sent to a computer running the Safeguard CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. For a social engineering story, the parallel is the out of band check that step 3 asks your help desk to make: the decision happens on a device the right person holds, for an action they can read, not on a caller's word.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It is the same discipline as the consent grant review in step 5: an integration gets a scoped grant that someone chose deliberately, rather than broad read access that nobody owns.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit; it ends with the upgrade done and tests passing. If your review after an incident like this one leads you to rotate integration credentials or update the sync services that move PHI into business applications, this is how you would do that work with every step visible and approved.

Click through it at your own pace, or open it full screen.

To try Safeguard on your own repositories, download Safeguard and follow the CLI docs.

Quick check

Sources

• iRhythm: Form 8-K, Item 1.05, June 2026 (SEC EDGAR)
• iRhythm: Form 10-Q for the quarter ended 30 June 2026 (SEC EDGAR)
• iRhythm: press release, "iRhythm Provides Update on Cybersecurity Incident Previously Disclosed in June 2026," 2 October 2026 (PDF)
• iRhythm: Notice of Data Event
• Oregon Department of Justice: data breach list (iRhythm Technologies Inc. entry)
• California Attorney General: data breach list (iRhythm Technologies Inc. entry)
• HHS OCR: breach portal (landing page only; we could not load the report list)
• 45 CFR 164.402: definitions (Cornell LII)
• 45 CFR 164.404: notification to individuals (Cornell LII)
• 45 CFR 164.406: notification to the media (Cornell LII)
• 45 CFR 164.408: notification to the Secretary (Cornell LII)
• 45 CFR 164.410: notification by a business associate (Cornell LII)
• 45 CFR 164.412: law enforcement delay (Cornell LII)
• 45 CFR 164.308: administrative safeguards (Cornell LII)
• 45 CFR 164.312: technical safeguards (Cornell LII)
• CISA: Implementing Phishing-Resistant MFA (fact sheet)
• NIST SP 800-63B-4: Authentication and Authenticator Management
• Microsoft Learn: Use Face Check with Microsoft Entra Verified ID
• The Record: iRhythm data breach reports, 9 October 2026
• BankInfoSecurity: Cardiac monitoring firm iRhythm's hack affects 8.2 million, 16 October 2026
• HIPAA Journal: iRhythm data breach, 19 October 2026

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.