TL;DR: A single compromised Okta login gave attackers standing access to Hims & Hers’ Zendesk instance, exposing millions of customer records in a breach tied to a common third-party access pattern, according to Apono. The lesson is plain: zero standing privilege, not just stronger authentication, is now a healthcare governance requirement.
At a glance
What this is: This is an analysis of the Hims & Hers breach and the finding that standing third-party access, not a novel exploit, enabled exposure at scale.
Why it matters: It matters because IAM and NHI teams need to treat vendor-connected access as part of their own blast radius, especially where support systems and AI agents can inherit privileges.
By the numbers:
- In early February 2026, ShinyHunters targeted Hims & Hers as part of a broader campaign against companies using Okta for single sign-on.
👉 Read Apono’s analysis of the Hims breach and standing access risk
Context
Standing access is the core problem here. When a vendor or connected account can reach sensitive systems continuously, a single credential compromise can turn into direct data exposure without further escalation. That is an IAM and NHI governance failure, not just an authentication failure, because the access path remains valid after the login is stolen.
In healthcare, that risk is amplified by support tooling, delegated vendor access, and the growing use of AI agents that may inherit user permissions. The issue is not whether authentication is strong at the front door. The issue is whether the account still has anything valuable to reach after the attacker gets in. For most organisations, that answer is still yes.
Key questions
Q: How should security teams handle standing access for third-party vendors?
A: Security teams should remove continuous access wherever the business task does not require it and replace it with short-lived, auditable privilege. The practical goal is to ensure a stolen vendor login cannot immediately reach sensitive systems. Third-party access should be reviewed like any other privileged identity, with scope, duration, and revocation tested regularly.
Q: What is the difference between zero standing privilege and just-in-time access?
A: Zero Standing Privilege is the access model that eliminates persistent privilege by default. Just-in-Time access is the operational mechanism that grants permission only when needed and removes it afterward. In practice, ZSP is the policy goal, while JIT is one way to implement it. Teams need both policy and automation to make the model work.
Q: Why do support accounts create outsized breach risk?
A: Support accounts often reach multiple customer-facing systems and may bypass normal least-privilege controls for convenience. If one of those accounts is compromised, the attacker can move directly into sensitive data without searching for additional permissions. That makes support access a high-value target and a strong candidate for task-scoped privilege and stricter review.
Q: Should organisations treat AI agents like privileged identities?
A: Yes. AI agents can inherit credentials, act quickly, and interact with tools that expose data or trigger actions, so they create the same governance problem as other non-human identities. Organisations should assign them explicit scope, logging, approval boundaries, and revocation rules rather than assuming human user controls will be sufficient.
Technical breakdown
Why standing access defeats least privilege in connected platforms
Standing access means an identity retains persistent permission to a system even when no task is underway. In a connected platform, that identity is often a vendor account, service account, or delegated support login with broad reach into tickets, data, or admin workflows. Once the credential is compromised, the attacker does not need to hunt for more permissions because the permissions are already present. This is why IAM controls that stop at authentication miss the real problem. The failure is not only who logged in, but what that login can continuously do across the environment.
Practical implication: Review every third-party and support account for continuous reach into sensitive systems and remove persistent privileges where possible.
How ZSP, JIT, and JEP change the attack surface
Zero Standing Privileges removes default access, Just-in-Time access grants permission only for a specific task window, and Just-Enough Privilege constrains that access to the minimum required scope. Together they reduce the time and breadth available to an attacker who steals a credential. The architectural shift matters because many enterprise and vendor workflows still rely on always-on access for convenience. In NHI terms, the same logic applies to service accounts, tokens, and agent identities. If access exists before the request and after the task, it is standing privilege.
Practical implication: Use task-scoped access for support, administration, and automation instead of permanent entitlements tied to a shared login.
Why vendor-connected identities need their own governance model
Vendor access often sits outside the customer’s direct control, yet it still reaches inside the customer’s security boundary. That makes it a non-human identity governance issue as much as a third-party risk issue. The correct model is not to assume a vendor is trustworthy because it uses SSO. The model is to require auditable scope, short-lived privilege, and revocation that actually happens when work ends. Healthcare buyers should also consider how AI agents extend these pathways, because agentic systems can inherit the same broad access patterns and move faster once compromised.
Practical implication: Treat vendor and agent identities as part of the same governance inventory and review them with the same access-review discipline as internal privileged accounts.
Threat narrative
Attacker objective: The attacker’s objective was to reach customer data through a trusted support platform using one compromised identity.
- Entry via social engineering against employees who were directed to enter credentials and MFA codes on phishing pages.
- Escalation was unnecessary because the compromised Okta SSO account already had standing access to Zendesk.
- Impact came from direct access to millions of support tickets and associated customer data without lateral movement.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
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 debt that makes ordinary credential theft catastrophic. The Hims case is not an edge case. It is what happens when continuous permissions survive beyond the business task that justified them. For IAM teams, the lesson is that access reviews must focus on live privilege paths, not only on authentication strength. The practical conclusion is to eliminate persistent access wherever a task-scoped model is viable.
Zero Standing Privileges should be treated as a third-party control, not only an internal admin control. Vendor accounts, delegated support logins, and outsourced operations often carry more reach than internal users realise. That makes external access a board-relevant governance issue because customer data exposure can follow a vendor compromise. Practitioners should require auditable short-lived access for every partner that touches sensitive systems.
Ephemeral credential trust debt: the longer a credential remains valid, the more the organisation pays for the assumption that the holder is still safe. Once that assumption breaks, every persistent entitlement becomes part of the incident blast radius. The Hims pattern shows why NHI governance must include support accounts, API-driven access, and any identity that can survive a single compromised login. The conclusion is simple: reduce the lifetime of trust, not just the strength of login checks.
AI agents will widen this problem unless their access model is constrained up front. The article correctly points out that agents inherit credentials and can accelerate misuse once access exists. That means the governance model must handle both human and non-human execution paths with the same least-privilege logic. The practitioner takeaway is to design access for autonomy without permanence.
From our research:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why standing access remains difficult to audit at scale.
- The next control priority is to pair access inventory with lifecycle enforcement, as detailed in Ultimate Guide to NHIs , Key Challenges and Risks.
What this signals
The programme-level signal is that third-party access review can no longer be an annual checkbox. If a vendor account can still reach production support systems after a single login compromise, the organisation has not reduced risk, it has outsourced it. The response is to inventory every externally reachable identity and move sensitive access into short-lived workflows.
Identity blast radius: the more systems a single credential can reach, the more a small compromise becomes a disclosure event. For healthcare teams, that means support tooling, ticketing platforms, and administrative consoles need the same least-privilege design discipline that people usually reserve for production infrastructure. The question is no longer whether an account is authenticated, but how much damage it can do before revocation catches up.
For practitioners
- Inventory every standing vendor access path Identify all third-party logins, support accounts, and delegated admin paths that can reach customer data or sensitive workflows, then map whether each one is truly required continuously.
- Replace persistent privilege with task-scoped access Move sensitive access to Just-in-Time workflows with explicit approval, short duration, and automatic revocation when the task ends. Prioritise the systems that contain regulated data or high-volume support records.
- Separate authentication from authorisation reviews Verify not just that SSO or MFA is enabled, but that the account still has meaningful authorisation after login. A secure login is not enough if the account can still read, export, or administer data.
- Apply the same controls to AI agents and service accounts Treat agent identities, API keys, and service accounts as governed identities with scoped entitlements, expiry, logging, and periodic review. Do not let automation inherit broader access than a human operator would receive.
Key takeaways
- The breach demonstrates that standing access, not exotic exploitation, is often the decisive failure mode in healthcare identity incidents.
- Persistent vendor and support entitlements create a large identity blast radius that authentication alone cannot contain.
- Security teams should replace continuous privilege with task-scoped access for both human and non-human identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Standing access and rotation failures map directly to NHI privilege controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management is central to the breach pattern described here. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous verification, which standing access undermines. |
Apply Zero Trust to third-party and support identities by requiring fresh authorization for sensitive actions.
Key terms
- Standing Access: Standing access is persistent permission that remains active even when no task is underway. In NHI and IAM programmes, it increases the blast radius of a stolen credential because the attacker inherits ready-made reach into systems, data, or administrative functions without needing fresh approval.
- Zero Standing Privileges: Zero Standing Privileges is an access model in which no identity keeps permanent elevated access by default. Privileges are granted only when needed, for a specific task, and then removed. It is a practical control pattern for reducing exposure in both human and non-human identity environments.
- Just-in-Time Access: Just-in-Time access is a control that provisions privilege only at the moment it is required and revokes it when the task ends. It shortens the window in which a compromised identity can be abused and is most effective when paired with approvals, logging, and narrow scope.
- Identity Blast Radius: Identity blast radius is the amount of damage a single compromised identity can cause across systems, data, and workflows. The larger the radius, the more urgent it becomes to reduce standing access, limit entitlements, and separate authentication from actual authorisation.
Deepen your knowledge
Standing access, task-scoped privilege, and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to reduce vendor-connected exposure, this is a practical place to start.
This post draws on content published by Apono: The Hims Data Breach and the cost of standing access in healthcare. Read the original.
Published by the NHIMG editorial team on 2026-04-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org