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
