Notifications
Clear all
Topic starter
12/06/2026 1:10 am
TL;DR: The Okta breach illustrated how compromised credentials, third-party access, and weak application approval controls can let attackers move from an endpoint into SaaS accounts, exposing 366 customer accounts before the incident was clarified by Okta. Identity protection has to be unified across access paths, because scattered controls leave attackers room to pivot.
NHIMG editorial — based on content published by Zluri: Security & Compliance Lessons from the Okta Breach for IT Asset Managers
By the numbers:
- Okta stated that 366 customers' accounts might have been accessed as a result of the incident.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
Questions worth separating out
Q: What breaks when third-party support access is not tightly governed?
A: When support access is loosely governed, attackers can pivot from an external endpoint into SaaS credentials, administrative accounts, and mailbox persistence.
Q: Why do SaaS identities create such a large attack surface after a breach?
A: SaaS identities are powerful because a valid session can unlock email, storage, delegated apps, and admin changes without needing new exploits.
Q: How do security teams know whether their identity controls are actually working?
A: They should measure whether compromised access is contained before attackers can create persistence, add applications, or move into another identity domain.
Practitioner guidance
- Treat third-party support devices as identity assets Apply endpoint controls, credential isolation, and monitored remote access to any device used by external support staff.
- Review mailbox rules and delegated permissions continuously Alert on new forwarding rules, newly created accounts, and changes to delegated access immediately after authentication.
- Require approval for new SaaS applications Block application creation or replacement in SSO flows until the app owner, requested scopes, and business justification are reviewed.
What's in the full article
Zluri's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step walkthrough of the Lapsus$ attack chain through the third-party support endpoint.
- Specific examples of SaaS and IT control gaps, including RDP exposure and mailbox forwarding abuse.
- Practical recommendations for least privilege, application approval, and incident notification governance.
- Zluri's SaaS security positioning and product context around identity and access control.
👉 Read Zluri's analysis of the Okta breach and identity attack lessons →
Okta breach lessons: what IAM teams should change now?
Explore further
12/06/2026 10:55 am
Identity governance failed at the boundary between support access and SaaS control. The Okta breach worked because the attacker did not need to defeat core authentication first. They entered through a third-party support endpoint, harvested credentials, and then used legitimate SaaS mechanisms to deepen access. That is a governance failure, not just an endpoint failure. Practitioners should treat third-party support identity as part of the production trust boundary.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Who is accountable when a third-party identity compromise leads to customer exposure?
A: Accountability sits with the organisation that owns the trust relationship, not only with the vendor or subcontractor involved. If a third party can reach production identities, the internal team must own approval, lifecycle review, monitoring, and revocation. Shared responsibility does not remove the need for clear internal ownership.
👉 Read our full editorial: Okta breach lessons show why identity is the real attack surface
