Okta's Second Breach in Two Years: When Your Identity Vendor Keeps Getting Compromised

In October 2023, Okta disclosed that attackers had compromised its customer support case management system using stolen credentials. The breach initially appeared limited: Okta reported that only 1% of its customer base had been affected. Weeks later, the company revised that figure to 100% of all Okta customer support customers. This was not Okta's first security incident — the Lapsus$ group had breached one of Okta's third-party support providers in January 2022. The recurrence raised a fundamental question for every organization dependent on Okta: how many times can your identity vendor get compromised before you reconsider the relationship?

What Happened: The Attack Chain

The attack began when threat actors obtained credentials to Okta's customer support case management system. Once inside, the attackers accessed HTTP Archive (HAR) files that customers had uploaded to support cases for troubleshooting purposes. HAR files are browser session recordings that capture network traffic, and critically, they often contain session tokens and cookies. With valid session tokens extracted from these HAR files, attackers could impersonate customers without needing their actual usernames or passwords.

Okta acknowledged the breach on October 20, 2023, initially stating it affected approximately 134 customers, which represented roughly 1% of its customer base. However, on November 29, 2023, Okta's Chief Security Officer David Bradbury disclosed that the actual impact was far broader: the threat actor had run a report that contained names and email addresses of all Okta customer support system users.

BeyondTrust and Cloudflare: Customers Who Caught the Breach First

One of the most notable aspects of this incident was that Okta did not discover the breach on its own. BeyondTrust detected suspicious activity on October 2, 2023 — more than two weeks before Okta's public disclosure. According to BeyondTrust's published account, their security team identified an identity-centric attack on an in-house Okta administrator account. They notified Okta on October 2 but reported that Okta did not confirm a breach for over two weeks.

Cloudflare also detected and mitigated an attack stemming from the Okta compromise. On October 18, 2023, Cloudflare's security team identified suspicious activity involving an Okta session token that had been compromised via the support system. Cloudflare's rapid detection and containment prevented any impact on their systems or customers. Both companies published detailed blog posts about their experiences, which ultimately pressured Okta into a more complete public disclosure.

"We identified the threat activity and immediately locked down the compromised account before the attacker could take any action on our systems." — Cloudflare Security Incident Report, October 2023

A Pattern of Incidents: The Vendor Trust Problem

The October 2023 breach was not an isolated event. In March 2022, Okta confirmed that the Lapsus$ hacking group had accessed the laptop of a support engineer at Sitel, one of Okta's third-party customer support providers. That incident affected up to 366 Okta customers. Okta's initial response was also criticized as slow and minimizing.

This pattern — repeated breaches, delayed disclosures, and downplayed impact assessments — creates a significant challenge for third-party risk management programs. Identity providers like Okta sit at the center of enterprise security architectures. They manage authentication and authorization for thousands of applications. A compromise of the identity provider is not equivalent to a compromise of any other vendor; it potentially gives attackers keys to every connected system.

The TPRM Challenge: When Do You Lose Trust?

For risk managers, the Okta situation exposes a difficult decision. Replacing an identity provider is enormously expensive and disruptive, often involving months of migration work. But continuing to trust a vendor with a pattern of breaches also carries clear risk. This is precisely the kind of scenario where quantitative risk analysis outperforms qualitative ratings. A vendor rated "medium risk" on a questionnaire provides no decision support. A FAIR-based analysis that estimates the annualized loss expectancy of continued reliance versus migration cost provides an actionable comparison.

Risk Mitigation Strategies

Organizations relying on any identity provider should consider several defensive measures in light of the Okta incidents:

• HAR file sanitization: Before uploading HAR files to any vendor support system, strip session tokens, cookies, and other sensitive data. Okta itself now recommends this practice.
• Session token monitoring: Implement detection for session token reuse from unexpected locations or IP addresses, which can indicate token theft.
• Vendor incident tracking: Maintain a formal record of vendor security incidents, response times, and disclosure accuracy. Use this history in risk assessments and contract renewals.
• Concentration risk analysis: Map all applications and systems that depend on your identity provider. Understand the blast radius of a compromise and consider architectural controls like network segmentation.
• Contractual protections: Include breach notification timelines, audit rights, and security performance requirements in vendor agreements.