What happened
Between February 4 and February 7, 2026, an unauthorized third party accessed Hims and Hers Health's Zendesk customer support platform by compromising Okta single sign-on credentials belonging to two employees.
The compromise was achieved through a social engineering attack consistent with the ShinyHunters threat group's vishing campaign targeting IT support staff at multiple organizations. Attackers called employees, impersonated internal IT support, and tricked them into entering credentials and MFA codes on attacker-controlled phishing pages. Once inside the Okta SSO accounts, attackers pivoted to the connected Zendesk instance and exfiltrated support tickets containing customer names, contact information, and details related to support requests.
Hims and Hers disclosed the incident in its FY2026 Q1 10-Q filing. Detection of suspicious activity began on February 5, the day after initial access. The investigation confirmed unauthorized access on March 3, and customer notifications began in April 2026. The ShinyHunters threat group was publicly identified as the actor by named journalism that same month.
The IAM control that failed
Three control failures compounded. None of them was a technical exploit of Okta itself.
Authentication controls did not survive a social engineering attack. The MFA in use was not phishing-resistant. The attackers used adversary-in-the-middle phishing, a pattern that defeats SMS, push notifications, and code-based MFA but is defeated by FIDO2/WebAuthn hardware-bound authenticators. The specific MFA factor type Hims and Hers had in place at the time of the breach is not in the public record, but the success of the attack tells the story.
Help desk and employee identity verification procedures created the opening. The social engineering attack relied on employees believing the caller was internal IT support. Strong identity verification procedures (callback to known internal numbers, out-of-band verification, and a firm rule against accepting credential-related requests over inbound calls) would have prevented the credential capture. The public record does not specify what verification procedures Hims and Hers had in place, so we treat this as a contributing factor consistent with the broader ShinyHunters campaign pattern across multiple victims.
The most consequential failure was structural, not procedural. Compromising one Okta SSO account gave attackers access to a Zendesk instance containing millions of support tickets. The blast radius of a single compromised SSO account was effectively the entire customer support corpus. The control question here is about session controls, just-in-time access, and the scope of permissions granted to standard support roles. If the support role had been scoped to active tickets only, or if access to historical tickets had required a separate elevation, the exfiltration window would have been measured in thousands of records, not millions.
What a competent IAM program would have caught
Phishing-resistant MFA on accounts with access to sensitive data closes the access vector. FIDO2/WebAuthn hardware-bound authenticators do not relay through attacker-controlled phishing pages the way push and code-based MFA do.
Help desk and IT support procedures that refuse to handle credential-related requests over inbound calls, with documented callback verification to known internal numbers, eliminate the social engineering payload. This is a process control, not a technology control, and it does not require new tooling.
Session-level controls and just-in-time access for high-volume data access patterns shrink the blast radius. A support agent accessing one ticket is normal. A support agent accessing one million tickets in three days is not. Detection on that pattern, with alerting and automatic session termination, transforms a catastrophic exfiltration into a contained incident.
Open questions
The specific MFA factor type in use at Hims and Hers at the time of the breach is not in the public record.
The exact number of support tickets accessed is not disclosed beyond "millions" in named journalism.
The identity verification procedures in place for help desk and IT support interactions, and whether those procedures were tested against social engineering scenarios, have not been described publicly.
Whether other downstream SaaS applications connected to Okta SSO were accessed beyond Zendesk has not been confirmed.
The full attribution chain for ShinyHunters is still developing in public reporting.
What this means for your program
Five questions to take to your IAM team this week.
Is our MFA phishing-resistant for high-privilege accounts and accounts with access to sensitive data? Where are we still using push, SMS, or code-based MFA on accounts that could be high-value targets, and is the gap defensible?
What are our help desk and IT support identity verification procedures, and when were they last tested against a social engineering scenario? If an employee receives a call from "IT support" asking them to log into a verification page, what stops them?
For every SSO account in our environment, what is the blast radius of a compromise? If one support agent's Okta credentials were stolen today, how many SaaS applications, how many records, and how much historical data is reachable from that one account?
Do we have session-level controls and just-in-time access for high-volume data access patterns? Where is the detection that catches a support agent accessing one million tickets in three days, and who gets alerted?
For our third-party SaaS platforms that hold customer data, what authentication trust chain connects them to our IdP? Are those trust chains documented, reviewed, and monitored, or are they configurations someone set up two years ago that nobody has revisited?
Sources
See the sources block in this teardown's frontmatter for the canonical reference list. Primary sources for the analysis above: Hims and Hers Health, Inc. FY2026 Q1 10-Q filing; named journalism in BleepingComputer, Cybernews, and HIPAA Journal; and the Okta researcher blog on adversary-in-the-middle phishing patterns published in January 2026.