The Okta breach that hit BeyondTrust, 1Password, and Cloudflare

Most of the breaches in this series start with a CVE number. This one doesn’t — it started with a customer support workflow nobody thought of as an attack surface. In October 2023, Okta disclosed that an attacker had used a stolen credential to access its support case management system and pull HAR (HTTP Archive) files uploaded by customers troubleshooting sessions with Okta support (Okta). Those files are meant to help a support engineer debug a browser issue. They also happen to contain every cookie and session token active in the browser at capture time — which is exactly what the attacker used to hijack sessions at Okta customers, including BeyondTrust, 1Password, and Cloudflare (BeyondTrust).

Root cause

The chain started upstream of the support system: an Okta employee had signed into their personal Google account on a company-managed laptop, and credentials saved in that browser profile — synced from a compromised personal device — gave the attacker a foothold into an Okta service account with access to the support case management system (Okta). From there the attack didn’t need any additional exploit. HAR file uploads are a standard, expected part of Okta’s support process; a user experiencing a bug records a browser session and uploads it so support can replay the request. Nothing about that workflow is abnormal, which is precisely why it went unnoticed — the attacker wasn’t triggering alerts for unusual API calls or privilege escalation, they were reading files customers had voluntarily uploaded through the front door.

The structural failure is the same one that keeps showing up in this column: a token that should have been scoped, short-lived, or server-side-validated instead behaved like a durable bearer credential. Session cookies captured in a HAR file are fully live — replaying them elsewhere gets you the session, no MFA prompt, no login event, because as far as the receiving service is concerned the session already authenticated. Okta’s support tooling had no process to strip or flag session tokens embedded in an uploaded HAR file before an engineer (or, in this case, an attacker) could view its raw contents.

Blast radius

Okta initially scoped the incident narrowly, then had to widen it: BeyondTrust identified and reported anomalous Okta administrative activity to Okta on October 2, 2023 — Okta didn’t confirm a breach until October 19, more than two weeks after a customer had handed them the finding (BeyondTrust). 1Password separately detected suspicious activity on its own Okta instance in late September and reported it directly, only to be told initially that nothing indicated compromise (1Password). Cloudflare’s incident response found the attacker had used a session token stolen from the Okta breach to access Cloudflare’s Okta instance, create a backdoor account, and attempt to move into Cloudflare’s internal Atlassian and source control systems before Cloudflare’s own detections cut them off (Cloudflare). None of the downstream victims were breached through their own vulnerability — every one of them did everything right on their side of the relationship and still had to run incident response because the identity provider’s support tooling was the weak point.

That’s the real lesson in the blast radius, not the specific companies: an IdP breach doesn’t cost you your IdP, it costs you every downstream system your IdP is trusted to authenticate into. SSO exists specifically to concentrate authentication into one provider, which means a compromise of that provider inherits the combined blast radius of every application behind it — the consolidation that makes SSO operationally sane is the same property that makes an IdP breach categorically worse than a breach of any single downstream app.

Remediation

Okta’s own fix was narrow and mechanical once the root cause was understood: restrict and eventually disable HAR file uploads to support, and where they’re unavoidable, scan and redact session tokens before an engineer can view the raw file (Okta). That’s the vendor-side patch, and it doesn’t require any action from you — but it also doesn’t address the part of the risk that lives on your side of the trust boundary.

If you run Okta or any SSO provider as your identity backbone, the actionable items are the same ones that would have limited or prevented downstream impact here. Never upload a HAR file, browser session export, or crash dump to a support ticket without scrubbing cookies and authorization headers first — treat “capture my browser session and send it to support” as equivalent to handing over a password, because functionally it is. Enforce short session lifetimes and re-authentication for sensitive admin actions in your identity provider’s admin console specifically, since that’s the account tier attackers actually want. Turn on and monitor for the IdP’s own anomaly signals — Cloudflare caught this because they had detections tuned to their own environment, not because Okta’s alerting flagged it for them. And treat any “no evidence of compromise” response from a vendor as provisional, not final: 1Password’s own detections were right, and the vendor’s first answer was wrong.

The bigger lesson

Vendor risk assessments tend to focus on the product surface — API authentication, encryption at rest, RBAC granularity — because that’s what’s contractually visible. This breach happened in a place no questionnaire asks about: the support case system a vendor’s own employees use to help you, staffed by people whose personal device hygiene isn’t something any customer audits. If your security model depends on trusting an identity provider, it also depends on trusting every internal tool that provider’s employees touch, and that dependency doesn’t show up in any SOC 2 report. The practical takeaway isn’t “don’t use SSO” — concentrating authentication is still the right architecture. It’s that concentrating authentication means your incident response plan needs a “what if the IdP itself is the incident” branch, because when it happens, it happens to everyone downstream at once, and you won’t be the one who gets to decide how fast it’s disclosed.