Hims breach shows standing access is the real healthcare risk

At a glance

What this is: This is a breach analysis showing how one compromised SSO account with standing access let attackers reach a connected healthcare system and expose millions of customer records.

Why it matters: It matters because IAM, PAM, and vendor governance teams need to treat persistent third-party access as a live breach path, not a theoretical risk.

Context

Standing access is the condition where an account can use a system continuously without requesting fresh privilege for each task. In healthcare, that model becomes dangerous when a vendor or support account can reach sensitive data through a connected platform and the organisation has little visibility into when, why, or how that access is used.

The Hims & Hers case shows why this matters for NHI governance as well as human IAM. A single compromised login became an open path to Zendesk because the privilege already existed, which means the control failure was not authentication alone but the decision to leave access resident after the session began.

Key questions

Q: What breaks when a vendor account has standing access to healthcare systems?

A: When standing access exists, a stolen or phished login can immediately reach connected systems without another privilege decision. In healthcare, that means support tools, case records, and other regulated data may be exposed even if authentication is strong. The control failure is persistent entitlement, because the compromise becomes usable the moment the account is taken over.

Q: Why does standing access increase breach impact in healthcare?

A: Because the attacker does not need to wait for a separate approval or discover a hidden escalation path. If the account already reaches sensitive applications, the attacker can act inside the normal business workflow and extract data at scale before containment catches up. That is why privilege scope, not only login assurance, determines the real blast radius.

Q: How do teams know whether zero standing privilege is actually working?

A: Teams should look for evidence that privileged access is time-bound, fully revoked, and impossible to reuse outside the approved session. If old secrets remain valid, break-glass accounts stay active, or administrators can operate without a fresh grant, ZSP is only partially implemented.

Q: What should organisations do after a third-party account is found to be the entry point for a breach?

A: After a third-party account is identified as the entry point, organisations should revoke exposed credentials, review all connected access paths, reset affected sessions, and determine whether the same trust relationship exists elsewhere. They should also validate logs, notify internal stakeholders, and tighten vendor controls before restoring normal access. The key objective is to stop lateral movement and prevent repeat exposure through the same relationship.

Technical breakdown

How standing access becomes breach-ready

Standing access turns a compromised identity into an immediately usable path because the privilege is already present when the attacker arrives. In this case, the attackers did not need to break a separate authorisation layer after taking over the Okta account. They inherited the account's existing ability to reach Zendesk, which is the practical difference between having an account and having a governing access model. The issue is not only the login event, but the persistence of the entitlement behind it.

Practical implication: review where vendor and support identities hold always-on access to sensitive applications, not just where they authenticate.

Why zero standing privilege changes the attack math

Zero Standing Privileges removes the assumption that access should be available by default. Just-in-Time access grants privilege only for the task window, and Just-Enough Privilege limits that access to the minimum scope needed to complete it. That means a compromised account may still authenticate, but it cannot automatically use sensitive downstream systems unless privilege is issued for that moment and purpose. In healthcare environments, that shifts the control point from post-login detection to pre-access authorisation and short-lived entitlement issuance.

Practical implication: design vendor access so the default state is no usable privilege until a specific task is approved.

What healthcare third-party access exposes beyond authentication

Third-party access is risky because it often extends beyond the vendor's own environment into customer systems that hold regulated data. When a vendor account is tied to support workflows, the access path can include tickets, case notes, and other operational data that reveal customer details even if the underlying platform is not the primary record system. That makes the governance problem broader than credential theft. It becomes a question of whether external accounts are scoped, monitored, and retired with the same discipline as internal privileged access.

Practical implication: treat every vendor account that can touch ePHI as an external privileged path subject to the same lifecycle controls as internal admin access.

Threat narrative

Attacker objective: The attackers sought customer data exposed through support workflows and used the persistent vendor access path to extract it at scale.

1. Entry occurred through a phishing-led compromise of an Okta SSO account after attackers impersonated IT support and captured credentials plus MFA codes.
2. Credential access was sufficient because the account already had standing access to the Zendesk instance, so no additional privilege escalation was needed.
3. Impact followed immediately as the attackers accessed and removed millions of support tickets containing customer names, contact information, and support interaction details.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing access is the governance failure, not the phishing event. The phishing step explains how the attackers entered, but the breach became material because the compromised account already held usable access to Zendesk. That is a lifecycle and privilege design failure, not an authentication-only failure. The practical conclusion is that persistent privilege on connected systems must be treated as part of the attack surface itself.

Zero standing privilege is now a healthcare control requirement, not an optimisation choice. Healthcare organisations handling ePHI cannot rely on login strength alone if downstream access remains permanently available. JIT and JEP matter here because they reduce the amount of time and scope in which a compromised identity can be abused. Practitioners should view resident access as incompatible with regulated support workflows unless the exposure can be tightly justified.

Vendor access without lifecycle offboarding creates borrowed-risk accumulation. Third-party accounts often outlive the original business need, especially when support relationships, platform integrations, or tool access change over time. That creates a standing entitlement that is easy to forget and hard to audit. The implication is that access reviews must focus on whether external privileges still have an active business owner, not simply whether the account still exists.

Healthcare trust now depends on proving privilege boundaries across humans and connected services. The article points to a broader market shift: covered entities increasingly want evidence that vendors can demonstrate auditable privilege controls before sensitive data is shared. That expectation aligns with OWASP-NHI concerns around overprivileged and long-lived access, and with NIST CSF access-control outcomes. The field is moving from authentication proof to privilege-proof, and buyers should respond accordingly.

AI agents will widen the same standing-access problem if they inherit vendor privilege by default. The article's warning about agent access is not separate from the human issue; it is the same governance flaw expressed through a faster actor. If an agent can reach ePHI through standing entitlement, the attack surface expands from data access to task execution. Practitioners need to rethink whether delegated access should exist at all unless it is issued per action and per context.

From our research library:

• Only 36% of health IT leaders say their organisation applies a privileged access strategy consistently across the enterprise, according to Ponemon Institute research.

What this signals

Standing privilege creates borrowed risk that authentication alone cannot absorb. Once a vendor or support identity can reach sensitive systems continuously, the organisation inherits whatever compromise state that identity later enters. The governance shift is simple to state and hard to execute: access should be issued at the moment of need, not banked in advance.

Borrowed access becomes board-level exposure when healthcare data is in scope. The operational problem is not just that one account was compromised, but that the access model allowed the compromise to become a disclosure event. Teams should expect auditors and customers to ask how external privilege is proven, scoped, and retired across the full lifecycle.

For practitioners

• Map every standing vendor access path Inventory third-party accounts that can reach regulated systems, then confirm whether each one still needs always-on access to production data or support tooling.
• Move support workflows to Just-in-Time issuance Require task-scoped privilege for external support and integration accounts so access is created only when a specific request is active and removed when the task closes.
• Recertify external entitlements against business ownership Tie each vendor account to a named internal owner, a defined use case, and a renewal date so stale access can be revoked before it becomes invisible risk.
• Test whether a compromised SSO account can still reach sensitive systems Run tabletop exercises that assume the login is lost to an attacker and verify that downstream access cannot be used without fresh approval or task evidence.

Key takeaways

• The breach shows that persistent third-party access can turn a single compromised login into direct exposure of regulated healthcare data.
• The article says millions of customer records were exposed, and attackers did not need escalation once they reached the connected platform.
• The limiting control is zero standing privilege, because task-scoped access removes the reusable entitlement that made the compromise exploitable.

Key terms

• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Just enough privilege: Just enough privilege is the practice of granting only the access needed for a specific workload, task, or time window. For NHIs, it works best when privileges are tied to a single function and expire automatically, reducing the chance that a leaked credential can be reused broadly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.