TL;DR: The Okta breach showed how compromised credentials, third-party support access and fragmented controls can let attackers pivot from one endpoint into SaaS environments, with Okta initially saying up to 366 customer accounts may have been affected, according to Zluri. Identity has to be protected as one attack surface, because split controls leave room for credential abuse and access drift.
At a glance
What this is: This is an analysis of the Okta breach that argues identity, not infrastructure alone, is the real attack surface when third-party access and compromised credentials are in play.
Why it matters: It matters because IAM, PAM and SaaS governance teams need to treat support access, app approvals and credential handling as one connected control plane rather than isolated checkpoints.
Context
The central governance problem is that identity controls are often split across endpoint security, SaaS access, third-party support and application approvals. When those controls are managed separately, attackers can move through the gaps by abusing credentials or delegated access rather than exploiting a single technical flaw.
In this article, identity means the account, credential or delegated access path that grants entry to a system or application. The Okta breach is used as a case study for why enterprise security has to assume that identity is the first thing attackers will target, especially when third-party support and SSO are involved.
Key questions
Q: What breaks when third-party code runs with the same privileges as internal code?
A: When third-party code runs with the same privileges as internal code, the browser no longer distinguishes trusted application logic from externally sourced content. Attackers can inject phishing prompts, redirect users to malicious sites, or silently exfiltrate credentials and personal data. The failure is not just code quality, but the loss of privilege separation and runtime control.
Q: Why does identity fragmentation increase breach risk in cloud and SaaS estates?
A: Identity fragmentation increases breach risk because it hides where access actually accumulates. A user or service can appear low risk inside one system while holding dangerous combinations across several others. That makes toxic access harder to detect, revocation harder to verify and privilege creep easier to miss during normal operations.
Q: How should teams decide which SaaS app permissions need approval?
A: Any application that can inherit a user's trust and request mail, storage, admin or workflow access should be treated as a governed identity event. If the app can widen the user's reach without a clear business justification and review path, it belongs behind an approval step and an access scope check.
Q: What should security teams do first after a SaaS identity provider compromise is suspected?
A: Security teams should immediately identify which account actions the compromised support path could perform, then search logs for those actions across the tenant. In this case, that means reviewing password resets, MFA factor changes, support access grants, and session impersonation events. The goal is to confirm scope, isolate unauthorized changes, and preserve evidence before the attacker can extend access.
Technical breakdown
How compromised credentials become the entry point
The attack path began with access to a third-party support engineer endpoint, then moved to credential harvesting and mailbox abuse. That sequence matters because once an attacker can reuse legitimate account material, they no longer need to break the application itself. In identity terms, the failure was not only the stolen password or token. It was the ability to turn one compromised workstation into trusted access to cloud services, support tooling and downstream account management. This is a classic identity abuse pattern: the adversary uses valid access artefacts to look like an authorised operator.
Practical implication: treat credential exposure and endpoint compromise as the same incident class when support staff or subcontractors can reach SaaS control planes.
Why distributed identity controls create blind spots
The article's core control insight is that identity protection spread across VPN, CASB and EDR creates seams attackers can cross one by one. A unified identity attack surface means every authentication and access attempt is assessed in context, regardless of whether the request comes through RDP, SSO or internal applications. This is not just about more tools. It is about making access decisions coherent across environments so that a risky login in one place can constrain access elsewhere. Without that linkage, attackers exploit the fact that each control sees only part of the session.
Practical implication: correlate authentication, device trust and application approval so one suspicious identity event can trigger broader access restriction.
Why delegated application access needs approval controls
The breach discussion also points to a common SaaS problem: when a user or attacker can add an application or replace an existing one, delegated permissions become a quiet escalation path. Application approval is not a procurement step, it is an identity control. If the SSO layer can authorise a malicious or over-broad app, the app inherits the user's trust context and can request mail or storage access that was never meant to exist. In practice, identity governance has to extend beyond human login to the apps and integrations that operate under that login's authority.
Practical implication: put explicit approval and review around new SaaS applications and delegated permissions before they inherit user trust.
Threat narrative
Attacker objective: The objective was to leverage trusted identity paths to reach customer and support data, then turn that access into broader visibility and operational leverage.
- Entry occurred when attackers compromised a third-party support engineer endpoint and gained a foothold through remote desktop access.
- Credential access followed when the attackers deactivated security tooling and obtained Office 365 account credentials tied to the acquired business.
- Escalation and impact came through mailbox forwarding, new account creation and visibility into customer-facing support materials and internal Slack content.
Breaches seen in the wild
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
- Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity is the real attack surface when third-party access is part of the trust chain. The Okta breach reinforces that attackers rarely need to break the core platform if they can compromise a support path that already carries authority. That shifts the security problem from perimeter defence to governance over who can act as whom, and under what delegated access. Practitioners should treat third-party identity paths as first-class attack surface, not just supplier management.
Distributed identity controls create a false sense of coverage. When VPN, EDR, CASB and SSO each own a slice of the decision, no single control sees the whole identity transaction. That fragmentation is especially dangerous in SaaS environments, where the same user identity can touch endpoints, mail, admin portals and application approvals in one workflow. The implication is that access governance must be unified across these layers, or attackers will keep using control seams as their route in.
Application approval is an identity control, not an admin convenience. The post's app-approval lesson is more important than it looks because delegated permissions can quietly extend a user's authority into mail, storage and other SaaS functions. If an attacker reaches the SSO plane, the real risk is not just login reuse but the ability to register or substitute apps that inherit trust. Practitioners need to treat app onboarding and delegated consent as privileged identity decisions.
Third-party support access should be governed with the same rigor as internal privilege. Support engineers and subcontractors often sit close to high-value SaaS workflows but outside the organisation's usual identity review routines. That is a governance gap, not an edge case. NHI Mgmt Group's position is that service-provider access becomes part of the enterprise identity model the moment it can influence customer data, admin workflows or message routing.
What this signals
Third-party support access is part of the enterprise identity model. The Okta case shows why supplier accounts cannot be left in a separate governance lane. If a contractor or support engineer can influence customer-facing SaaS, the access needs the same review, approval and offboarding discipline as internal privilege.
Access review processes are only useful when the access object stays visible long enough to be certified. In SaaS environments, forwarding rules, delegated apps and support sessions can create authority that outlives the user interaction that created it, so practitioners need controls that act at issuance and consent time as well as during periodic review.
For practitioners
- Unify identity event monitoring Correlate endpoint, SSO, mailbox and SaaS admin events so a compromise in one layer can restrict access across the rest of the identity surface.
- Review third-party support access Inventory subcontractor and support-engineer accounts, then verify which systems they can reach, which approvals they can grant and how quickly access is removed when role or vendor relationships change.
- Gate SaaS application approvals Require explicit review before new applications inherit delegated permissions in SSO, especially where an app can request mail, storage or other sensitive scopes.
- Tighten credential handling for support teams Reduce the value of stolen credentials by enforcing MFA, limiting session reuse and removing persistent access paths from contractor endpoints.
- Build identity-first incident response playbooks Define containment steps that begin with account isolation, token revocation and forwarding-rule review rather than waiting for endpoint cleanup alone.
Key takeaways
- The breach demonstrates that identity compromise can be enough to reach SaaS environments without attacking the application itself.
- The article cites an initial exposure estimate of 366 customer accounts, which shows how quickly a third-party access issue can scale.
- Teams need unified identity governance, because approval gaps and scattered controls give attackers multiple ways to reuse trust.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centres on a support provider path abused to reach Okta customer accounts. |
| NHI-04 — Insecure Authentication | Credential compromise and reused access are the article's main attack mechanism. | |
| NHI-05 — Overprivileged NHI | The attack depended on access paths that carried more authority than the immediate task required. | |
| Recommendation — Inventory third-party identities that can reach SaaS control planes and revoke access paths that outlive the relationship. Harden authentication for support and admin access so stolen credentials do not become a durable entry point. Reduce standing authority for support and SaaS admin identities to the minimum scope needed for the task. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes credential theft followed by movement into SaaS accounts and internal systems. |
| Recommendation — Map the compromise to credential access and lateral movement to prioritise detections around support accounts and SaaS pivots. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The breach is fundamentally about mis-scoped access and delegated trust across identity paths. |
| Recommendation — Apply entitlement governance to review who can approve, inherit or extend SaaS access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential handling and reuse were central to the incident path. |
| Recommendation — Use authenticator management controls to reduce the lifetime and reusability of support credentials. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The incident exposes cloud identity governance gaps across SaaS, support and delegated access. |
| Recommendation — Strengthen cloud identity governance over SaaS users, support accounts and delegated permissions. | ||
Key terms
- Third Party Support Access: Third Party Support Access is the controlled ability for an external vendor, contractor, or service provider to enter an organization’s systems to diagnose, maintain, or resolve issues. It usually relies on time-bound credentials, scoped permissions, logging, and approval workflows to reduce exposure while preserving operational support needs.
- Identity Attack Surface: Identity attack surface is the total set of accounts, tokens, login endpoints, trust paths, and supporting systems that can be probed for access. For password spraying, the risk grows with every externally reachable authentication path and every dormant or weakly protected identity.
- Delegated permissions: Delegated permissions are access rights granted through another identity, application, or administrative relationship rather than directly to the end user. They matter because revoking the visible account does not always remove the underlying authority, which can preserve access after offboarding.
- Unified Identity Protection: A governance model that treats identity as the place where discovery, risk assessment, and enforcement meet. It combines state, policy, and runtime signals so teams can see not just who has access, but whether that access is still justified and enforceable across the session.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org