Was Okta's authentication product broken in these incidents?

No. In each case the attacker reached a system around the product: a third-party support provider's laptop, customer IT service desks, and Okta's own customer support case management system. That distinction matters because it means the lesson is about the operational surface surrounding an identity provider rather than about cryptographic or protocol weakness in single sign-on.

What happened in the October 2023 Okta support system breach?

Okta reported that between 28 September and 17 October 2023 an attacker accessed files in its customer support case management system relating to 134 of its customers. The credential used was for a service account that had been saved into an employee's personal Google profile while they were signed into Chrome on an Okta-managed laptop. Some of the accessed files were HAR files containing session tokens, which the attacker used to hijack sessions for five customers. 1Password, BeyondTrust and Cloudflare publicly described their own detection of the activity.

What is a HAR file and why is it dangerous?

An HTTP Archive file is a recording of everything a browser sent and received during a session, produced from developer tools. Support teams ask for them because they show exactly what went wrong. They also capture cookies, authorization headers and bearer tokens, so an unsanitised HAR file is a working copy of the user's authenticated session. Anyone who obtains it can replay that session without a password or a second factor.

How did attackers reset MFA by calling a help desk?

By impersonating an employee convincingly enough to pass identity verification, then asking for a multi-factor reset or enrolment of a new device. Okta published an advisory in 2023 describing social engineering against customer IT service desks aimed at highly privileged accounts. Once a new factor is enrolled on an attacker's device, the account is theirs and every downstream application trusts the resulting session.

What should a customer of any identity provider do about this?

Sanitise HAR files and diagnostic bundles before sending them to any vendor. Enable session binding and shorter session lifetimes for administrative accounts. Require strong identity verification for help desk MFA resets, ideally with a callback or manager approval for privileged accounts. Monitor for administrative sessions from unfamiliar locations. And keep break-glass accounts that do not depend on the provider being healthy or trustworthy.

The Okta Breaches: Session Tokens, HAR Files and a Support System

Q: What did the January 2022 incident involve?

Access to a laptop belonging to a support engineer at a third-party provider that delivered support services for Okta, over a period in January 2022. The activity became public in March 2022 when the group posted screenshots. Okta's initial assessment described up to 366 customers as potentially impacted, and its later analysis concluded that two customers were actually affected.

An identity provider sits underneath everything. It decides who a person is for every application behind it, so compromising it is a shortcut past every access control those applications have. That makes the company running it a permanent, high-value target, and it makes their operational surface part of yours.

Okta has had three distinct incidents that are worth studying together, because in none of them did anyone break single sign-on. The attackers went around it: through a vendor's laptop, through customer help desks, and through the support ticket system. The lessons are about the surfaces surrounding an identity provider rather than about the protocol.

Facts here come from Okta's own security advisories, from the published investigations of affected customers who detected the activity independently, and from the US Cyber Safety Review Board's review of the group involved in the 2022 case.

Three incidents

Period	Route	Reported impact
January 2022	A support engineer's laptop at a third-party support provider	Initially described as up to 366 customers potentially impacted; later analysis concluded two were affected
August and September 2023	Social engineering of customer IT service desks to reset MFA on privileged accounts	Multiple customers, described in an Okta advisory
28 September to 17 October 2023	Okta's customer support case management system, via a service account credential	134 customers' files accessed; sessions hijacked for five

January 2022: the vendor's laptop

Attackers obtained access to a laptop belonging to a support engineer working at a third-party company providing support services for Okta. The incident became public in March 2022 when the group posted screenshots of internal tooling.

Two things make this instructive.

The access was a support engineer's. Support tooling frequently carries powerful capability, including resetting passwords and factors for customer accounts, because that is what support does. The account that can help a locked-out administrator is an account that can impersonate one.

The company was a subcontractor. Customers assessed Okta. Okta's assessment of its own support provider was between Okta and that provider, and it sat on the same path to customer data. Third-party risk is transitive and most vendor questionnaires stop at the first hop.

The disclosure itself became part of the story: the gap between the January access and the March public statement drew criticism, and the practical lesson for customers is that you may learn about a provider incident from a screenshot before you learn about it from the provider.

2023: calling the help desk

In 2023 Okta published an advisory describing a different technique aimed at its customers rather than at Okta. Attackers contacted IT service desks and persuaded staff to reset multi-factor authentication for highly privileged accounts, then enrolled their own factor.

This bypasses the entire authentication stack. It does not matter whether the account used a hardware key, because the help desk removed it and let a new one be enrolled. The strength of the factor is irrelevant when the reset path is a phone call.

The controls that answer it are procedural:

Strong identity verification before any factor reset, particularly for privileged accounts. A callback to a known number, a video verification against a record, a manager confirmation, or an in-person check.
A different, harder path for privileged accounts than for ordinary users.
Alerting on factor resets for anything in an administrative role, treated as a security event rather than a ticket.
Making it acceptable to say no. Help desk staff are measured on resolution speed and trained to be helpful, and the attacker is exploiting exactly that. The policy has to make refusing an unverified request the safe choice for the person on the phone.

Social Engineering Playbook covers the persuasion mechanics, and Privileged Access Management Explained covers the standard privileged accounts should be held to.

October 2023: HAR files in support tickets

This is the incident with the most transferable technical lesson.

The root cause. An Okta employee signed into their personal Google profile in Chrome on an Okta-managed laptop. The credentials for a service account used with the customer support system were saved into that personal profile, which meant they synchronised out to a personal Google account. The attacker obtained them and used the service account to access the support case management system between 28 September and 17 October 2023.

That path deserves attention because most device policies do not consider it. The laptop was managed. The credential was for a corporate service account. The synchronisation to a personal account happened through an ordinary browser feature working exactly as designed, and it moved a corporate secret outside every control the company had. Okta's remediation included blocking personal Google profiles in Chrome on managed devices, which is the direct answer. Browser Hardening Guide covers profile separation as a general practice.

What was in the tickets. Support cases contained HAR files. An HTTP Archive is a complete recording of a browser session, generated from developer tools, capturing every request and response including headers. Support engineers ask for them because they show precisely what a browser did.

They also capture cookies, authorization headers and bearer tokens. An unsanitised HAR file from an authenticated session is a working copy of that session.

What that enabled. The attacker used session tokens from those files to hijack sessions for five customers. Multi-factor authentication provided no protection, because the authentication had already happened before the recording was made. This is the mechanism in Session Hijacking Explained, delivered through a support process.

How it was found. Several customers detected the activity in their own environments and reported it. 1Password, BeyondTrust and Cloudflare each published accounts of noticing anomalous administrative activity. That detail is the most encouraging part of the case: customers monitoring their own identity provider tenants caught something before the provider's own investigation concluded.

The impact figure moved. The initially reported number was 134 customers, under 1% of Okta's customer base. A later review disclosed that the actor had also run and downloaded a report containing names and email addresses of users of the customer support system, a considerably wider set. Revision after initial disclosure is normal in incident response, and it is why a number without a date is not a fact worth repeating.

What customers should take from this

The recurring theme is that an identity provider's non-authentication surfaces are part of your security posture.

Sanitise diagnostic files before sending them anywhere. HAR files, browser traces, memory dumps and log bundles routinely contain live credentials and tokens. Browser developer tools and standalone sanitisers can strip cookies and authorization headers. Make it a documented step in your own support process, for every vendor.

Shorten and bind administrative sessions. Session lifetime for privileged accounts should be short, and sessions should be bound to a network location or device where the provider supports it. Okta's own remediation included binding administrator session tokens to network location, which makes a stolen token useless elsewhere.

Monitor your own tenant. The customers who caught this were watching administrative activity in their identity provider and noticed sessions that did not fit. Feed identity provider logs into a place decisions are made, as in What Is a SIEM, and alert on administrative sessions from new locations, new factor enrolments, and changes to authentication policy.

Harden the help desk path, because it is the reset that undoes every factor.

Assume vendor incidents reach you late and incomplete. Have break-glass accounts that do not depend on the provider, know how to revoke sessions in bulk, and rehearse the case where the identity provider itself is the thing you cannot trust.

Ask vendors about their subcontractors. The 2022 incident happened at a company most customers had never assessed.

The verdict

None of these incidents broke single sign-on. They went through a subcontractor's laptop, through help desks, and through a support ticket queue, and the last one turned an ordinary troubleshooting artefact into a set of working sessions.

The practical response is narrow enough to act on this week: sanitise HAR files before you send them, bind and shorten administrative sessions, put a hard identity check in front of any factor reset for a privileged account, and watch your own tenant closely enough to notice a session that should not exist.