MyRecon OSINTiRhythm 2026: June access, October notifications
- People affected
- Affected count not stated in the reviewed company update
- When it happened
- 3–8 June 2026
- Made public
- June 2026; notification update 2 October 2026
- How they got in
- Unauthorized access to third-party-hosted business applications; entry method not disclosed in the reviewed update
- Attributed to
- Not identified in the reviewed company update
What was exposed: Patient names · Contact information · Patient account numbers · Device serial numbers · Insurance numbers · Dates of service · Dates of birth
The story behind the breach
This case follows a company's account of data accessed in June and notifications sent in October. It keeps the incident timeline separate from the date a person learns about it.
How did it happen?
Unauthorized access to third-party-hosted business applications; entry method not disclosed in the reviewed update
Start with the categories stated in your own verified notice and record which actions it recommends. Keep it private. A broad company update describes the incident; it may not tell you which fields appear in your particular record. Reach the organisation through its official website before trusting an unexpected follow-up message. A breach catalogue and an individual notification serve different purposes.
The absence of a searchable email match should not override a verified notice. Conversely, a published incident record does not establish that a particular reader was affected. MyRecon's guide to no-match results explains this boundary.
What was the motive?
The published account does not establish the motive. We cannot tell what the attackers intended from the exposed data alone.
Claims and demands are reported as such; they do not establish every attacker's intention.
What was the outcome?
Reported scale: Affected count not stated in the reviewed company update.
Read the full account and timeline · 2 min
This case follows a company's account of data accessed in June and notifications sent in October. It keeps the incident timeline separate from the date a person learns about it.
The confirmed timeline
In its 2 October 2026 update, iRhythm said unauthorized parties accessed and downloaded data from certain third-party-hosted business applications between 3 and 8 June. The company detected the access around 8 June. After investigation and data review, it began notifying affected people with available contact information on 2 October.
The information involved
The company listed patient names and contact information, account and device identifiers, insurance numbers, service dates and birth dates. It said it does not retain individual financial-account or payment-card information and had not identified impact to products, clinical or medical-device systems, or patient safety.
What remains unknown
The reviewed update did not give an affected-person total, name an attacker or explain the initial access method. These fields remain unknown here. A record count of zero in a machine-readable field must not be read as a claim that nobody was affected.
Why the distinction matters
MyRecon analysis: a notification date is a communication milestone. Treating it as the intrusion date creates a misleading picture of recency and can cause readers to count one incident twice. A useful case record preserves the access window, disclosure and notification as separate facts.
Likewise, access to a business application does not by itself establish compromise of every system operated by an organisation. Keep the scope tied to the statement being cited. If a later disclosure expands that scope, update the case with its source and review date rather than quietly rewriting the original account.
How to read an individual notice
Start with the categories stated in your own verified notice and record which actions it recommends. Keep it private. A broad company update describes the incident; it may not tell you which fields appear in your particular record. Reach the organisation through its official website before trusting an unexpected follow-up message.
A breach catalogue and an individual notification serve different purposes. The absence of a searchable email match should not override a verified notice. Conversely, a published incident record does not establish that a particular reader was affected. MyRecon's guide to no-match results explains this boundary.
Review notes
Source reviewed 25 October 2026. This case contains no leaked records or personal medical data. It is based on the linked public company update; later findings may change the scope. Continue with breach and disclosure dates or the case archive.
Sources
Read next
Case files are written from the public record: regulatory findings, court filings, company disclosures and contemporaneous reporting, cited above. Figures are the ones the organisation or its regulator finally settled on, which is often not the number first reported, where that differs, the page says so. Disputed accounts are marked as disputed rather than resolved in either direction.