Okta support breach: a checklist to see if your org would catch it

Okta's 2023 support system breach is a useful test for any company. Ask whether you would notice a service account used from an odd IP, a vendor logging file views differently from case views, or a session token pulled out of a file you sent to a vendor. This checklist turns those facts into questions.

What does Okta say happened?

From Okta's published root-cause account: between 28 September and 17 October 2023, a threat actor had unauthorized access to files in Okta's customer support system. The actor used a service account that could view and update support cases. Its username and password had been saved in an employee's personal Google account, signed in to a Chrome profile on a company-managed laptop. Okta said the most likely exposure was a compromise of that personal account or device.

Files tied to 134 customers, under one percent, were accessed. Some were HAR files, which support asks customers for to replay browser activity, and which can contain session tokens. The actor used them to hijack legitimate sessions at five customers. Okta states that customers BeyondTrust and 1Password reported suspicious activity first, and that Cloudflare was identified as the fifth and final target.

One detail is easy to miss: Okta's first investigation looked at case access, and for about 14 days it did not identify file downloads, because viewing files through the Files tab produced different log events than files attached to cases. This is a story about logging gaps, which makes it relevant to everyone.

Okta's remediation included disabling the service account, blocking Chrome sign-in with personal Google profiles on managed laptops, adding detection rules, and releasing network-location session token binding for administrators.

The checklist: your side as a customer

• Do you sanitize HAR files before sending them to any vendor? Okta's guidance was to remove credentials, cookies and session tokens first. Do you have a written rule and a tool to do it?
• Would you notice a session used from a new network shortly after a support interaction? Check whether your identity provider can bind sessions to location or device, and whether alerts go to someone who acts.
• Do you review administrator sessions in your identity provider system log for unfamiliar IPs and user agents? Okta published indicators; do you have a routine for acting on a vendor's indicator list within a day?
• Do you have a named channel through which vendors can reach security with a warning, and does someone watch it? Customers noticing the odd activity is how this was found.

The checklist: your side as a vendor or operator

• Where do service account credentials live? Search laptops, browsers and shared notes. Browser password stores synced to personal accounts were the path here.
• Can managed browsers be restricted from signing in to personal profiles? Okta did exactly that afterwards.
• Do service accounts have an owner, a purpose, a network restriction and an alert on use from a new location?
• Do you log every way to read a file, not only the obvious one? Test it: open a record in each view and check the log.
• Do you have a second way to query logs and a check for gaps in the most recent hours? Okta found its logs had a gap near the end of the activity, and a re-run query returned a full picture.
• Can you revoke every token a customer might have shared in a file?

Where tooling helps

Detection like this is mostly identity and log work, and the answers above belong to your identity and logging stack. Where Safeguard helps is the software side: inventorying the applications and agents that hold credentials, and finding secrets committed into code or pipelines through secrets scanning.

What to do

1. Write and enforce a HAR file sanitization rule for support interactions.
2. Turn on session binding or equivalent in your identity provider.
3. Set up a routine to check vendor indicator lists against your logs within a day.
4. Search for stored service account credentials in browsers, notes and repositories.
5. Restrict personal profile sign-in in managed browsers.
6. Give every service account an owner, purpose and network restriction.
7. Test that each file access path produces a log event.
8. Check for log gaps after every investigation query.

Quick check

Sources

• Okta: Root cause of unauthorized access to the support case management system (3 November 2023)
• Okta: Tracking unauthorized access to Okta's support system (20 October 2023)

Last reviewed: 18 October 2026.