Okta support system breach, a service account on a personal laptop.

Summary

The Okta support system breach is the canonical modern example of what OWASP's NHI Top 10 captures as NHI10: Human use of NHI. The credential in question was a service account credential, issued to a machine identity for automated or shared use, but the credential material ended up stored in a personal Google account. When that personal account was compromised, the attacker inherited the service account's privilege. There was no multi-factor challenge on the service account itself; the assumption was that the service account would only ever be used by authorised employees from authorised infrastructure.

The breach is also instructive because the blast radius was shaped entirely by what customers had voluntarily uploaded to Okta support. HAR (HTTP Archive) files are a standard troubleshooting artefact, but they contain live authentication artefacts (session cookies, bearer tokens, SAML assertions) which, if captured while valid, permit session replay against the customer's own tenant. Three high-profile Okta customers, 1Password, BeyondTrust, Cloudflare, detected the downstream replay attempts and disclosed before Okta did.

Timeline (based on Okta's public disclosures)

How it happened: the credential path

The mechanical chain as Okta has publicly described it:

1. Okta issues a service account to a support engineer (or team) to authenticate to the internal support case-management system. This is a functional account, not a personal one.
2. The engineer, while using the service account, saves the credential into their personal Google account, either directly in Google's password manager or via a browser profile tied to their personal Google identity.
3. The engineer accesses the service account from a company-managed laptop on which that personal Google account is signed in.
4. The personal Google account is compromised (credential exposure or phishing, Okta has not publicly detailed the exact compromise).
5. The attacker harvests saved credentials from the personal Google account, including the Okta service account.
6. The attacker logs into the Okta support system using the service account. No MFA step on the service account blocks them.
7. Attacker downloads HAR files attached to open support cases and a support-user report.

The critical break was step 2, the moment at which a machine credential crossed into a personal identity surface. Everything downstream is mechanical.

Why HAR files mattered

HAR files record every HTTP transaction a browser performs during a session. They are a normal support artefact, a customer experiencing a confusing Okta issue is often asked to reproduce the problem while capturing a HAR file, then upload it so the vendor can see what actually travelled over the wire.

The problem: HAR files contain authentication artefacts verbatim. In a standard Okta session, this includes session cookies (including sid and DT), OAuth bearer tokens, and any SAML assertions that were emitted during the captured window. An attacker in possession of a HAR captured while the session was live can replay the cookies directly, bypassing login and MFA entirely, until the session expires or is revoked.

For customers who detected and responded quickly (Cloudflare, 1Password, BeyondTrust), the attacker's window of useful replay was small. For customers who didn't know, the replay window could have been substantial.

NHI root cause analysis

• NHI10, Human use of NHI (primary): the service account credential was handled as though it were a personal password. Saved to a personal password manager. Used from a browser profile tied to a personal identity. Once that happened, the service account's security properties were entirely dependent on the personal Google account's security properties, a coupling that was nowhere documented or intended.
• NHI4, Insecure authentication: the service account relied on a shared secret with no second factor. If it had required a workload-attested credential (mTLS, a device-bound OIDC token, SPIFFE SVID from a SPIRE node attestor), lifting the secret string from a password manager would have been insufficient.
• NHI9, NHI reuse: a single service account was used across multiple support engineers rather than issuing per-engineer or per-workstation service identities. Reuse expanded both the credential's surface area and the difficulty of tying activity to a human operator.
• NHI5, Overprivileged NHI: the service account could read HAR attachments and a full customer-contact report. The principle of least privilege would suggest these be separate scopes granted to different technical identities (triage read vs. report export).

Impact

• Direct exposure: approximately 134 customers had HAR files accessible to the attacker. A subset of those HAR files contained session material that was live at the time of access.
• Data exposure (extended): all support customers (~18,400 orgs) had contact-data exposed via the customer-support user report.
• Reputational: three of Okta's largest and most security-mature customers (Cloudflare, 1Password, BeyondTrust) detected the downstream effects before Okta did and disclosed first. This is the second significant Okta support-related incident in recent years (the Lapsus$ contractor incident being the first, in 2022).
• Market: Okta's stock fell ~11% on the day of the initial disclosure. Subsequent revisions drove further erosion.
• Industry: catalysed widespread customer review of what telemetry was being uploaded to support vendors and how long it persisted. Several organisations adopted HAR sanitisation as a pre-upload step.

Mitigation playbook (what to check in your own estate)

1. Inventory shared service accounts. Any service account used by more than one human, or whose credential can be extracted as a string, is a candidate for replacement. Pull the list and triage.
2. Move high-sensitivity service accounts to workload-attested authentication. SPIFFE/SPIRE SVIDs, mTLS with workload-bound certs, or OIDC with device-bound tokens remove the "secret in a password manager" failure mode.
3. Forbid personal password-manager storage of corporate service credentials. Enforce via corporate browser policy: block Google/Apple password manager on company SSO domains.
4. Apply MFA to service accounts where the use case permits. Many SaaS platforms now support second-factor on non-interactive accounts via signed device attestation or IP allowlisting. Use both where available.
5. Sanitise HAR uploads by policy. Several open-source HAR sanitisers exist; vendors including Okta now recommend running HARs through sanitisation before upload. Treat HAR uploads like any other sensitive export.
6. Detect session replay at the IdP edge. Bind sessions to device posture, client IP (with tolerance), TLS fingerprint. Alert on session resumption from a materially different context.
7. Audit vendor support privileges. Apply the same scrutiny to your support relationships (what can the vendor see? what can their staff export?) that you apply to privileged internal accounts.

Lessons for the field

The enduring lesson of the Okta support breach isn't about Okta. It's about the porousness of the line between human and non-human identity in everyday operational reality. Engineers save credentials in password managers. Password managers sync. Personal accounts are targets. When a machine credential ends up in that chain, even once, even briefly, its security properties collapse into whatever the weakest link in that chain happens to be.

The architectural response is to make service account credentials impossible to store in a password manager. Short-lived, workload-attested, non-transferable. If the credential cannot be written down, it cannot be saved to Chrome. That is the direction the industry is moving, via SPIFFE, WIMSE, and the broader push toward secretless authentication, and Okta's 2023 breach is one of the more vivid reasons why.

Sources

• Okta security advisories (October & November 2023), sec.okta.com
• Cloudflare disclosure: How Cloudflare mitigated yet another Okta compromise, October 20, 2023
• 1Password disclosure: What we've learned from the Okta breach, October 2023
• BeyondTrust disclosure: Okta support unit breach, October 2023

Frequently asked questions

What happened in the Okta support system breach?

An attacker gained access to Okta's customer support case management system and retrieved session tokens contained in HTTP archive files that customers had uploaded for troubleshooting. Those tokens could then be used to authenticate as the affected customer sessions. The initial access is reported to have involved a service account whose credentials had been saved to a personal Google profile on a company-managed device.

Why is the Okta breach an NHI incident?

Two non-human identity failures compound in it. The initial access route involved a service account credential that had escaped organisational control by being stored in a personal browser profile. The impact route involved session tokens, which are themselves non-human credentials, sitting in support artefacts where nobody had treated them as secrets. Neither failure required an exploit.

What are HAR files and why were they a problem?

An HTTP archive file is a recording of browser network traffic, commonly requested by support teams for troubleshooting. It captures headers, which means it captures session tokens and other credentials. Uploading one to a support portal therefore transfers live credentials to a third party's system. The general lesson is that diagnostic artefacts are credential-bearing and should be sanitised before they leave your boundary.

What should organisations change after this incident?

Three things. Prohibit and technically prevent saving corporate credentials into personal browser profiles on managed devices. Sanitise diagnostic artefacts before uploading them anywhere, and treat any that were uploaded as compromised. And shorten session token lifetimes so that a token captured in an archive expires before it can be used.