How the Okta breach happened: a work password saved to a personal Google account

The attacker who broke into Okta's customer support system did not beat Okta's own login product. They used a work password that an employee had saved into a personal Google account, synced through the Chrome browser on a company laptop.^[1] This case file covers how that one saved password exposed support files from 134 Okta customers, why it took weeks to spot, and the control that would have closed the door.

What happened

How they got in

Okta's investigation traced the break-in to a service account, a non-personal login used by the support system itself, with permission to view and update customer cases.^[1][3] An Okta employee had signed into a personal Google profile in Chrome on an Okta-managed laptop. The service account's username and password were saved into that personal Google account, which meant they were stored outside the company's control.^[1]

Okta said the most likely path was that the employee's personal Google account or personal device was compromised, handing the attacker a working company credential.^[1] From there, the attacker did not need to break anything. They logged in as the support system's own account, opened files customers had trusted Okta to hold, and reused the live session tokens inside them to walk into customer environments as already-authenticated users.^[1][3]

How it was caught

Customers, not Okta's own monitoring, spotted it first. Okta said it spent 14 days investigating without finding the suspicious downloads. The reason was mundane: the attacker pulled files through a different screen in the support tool, which wrote a different kind of log entry than the one Okta was searching for.^[1][4]

The break came on October 13, when BeyondTrust handed Okta an IP address tied to the attacker. On October 16 Okta used it to find the compromised service account, and on October 17 it disabled the account and revoked the exposed session tokens.^[1] Gaps in logging meant more affected files turned up on October 18 and 19.^[1]

What it cost

The damage kept growing after the first disclosure. On November 29, 2023, Okta said the attacker had also run a report that pulled the name and email address of nearly all of its customer support users. For about 3% of them, more fields were taken, such as phone numbers and job roles, and Okta administrators were heavily represented.^[5] Okta warned that the list could fuel phishing, and noted that about 6% of its customers, more than 1,000, ran administrator accounts without multi-factor authentication.^[5] For a company whose whole product is trust in logins, the reputational cost was the largest one.

The missing control

The missing control: blocking personal browser profiles on company machines. A work laptop should not let an employee sign into a personal Google or browser account that quietly copies company passwords to a place the company cannot see, secure or wipe.

With that setting in place, the service account's password would have stayed on the managed device, and a compromise of the employee's personal account or home computer would not have exposed it. Okta's own fix confirms the point: it blocked personal Google profile sign-ins on its managed Chrome browsers, added detections for both kinds of file download log, and began tying admin sessions to their network location so a stolen token is harder to reuse.^[1][3] A second lesson sits alongside it: a shared service account with wide access should never be a password a person can save anywhere.

What to do in your business

• Turn off personal browser sign-in on work computers. Chrome and Edge both have management settings that block personal profiles and password sync on company devices. Ask your IT provider to switch it on.
• Keep work passwords in a company password manager. Give staff an approved tool the business controls, so no one needs a personal browser or account to remember work logins.
• Treat shared accounts as high risk. List every login that is not tied to one person, such as support, admin or vendor accounts. Limit who knows them, add multi-factor sign-in, and change them when staff leave.
• Clean files before you send them to support. Before uploading browser logs or screenshots to any vendor, remove passwords and session data, and delete old uploads when the ticket closes.
• Put multi-factor on every admin account. The people with the keys are the ones attackers will phish first, so their accounts need the strongest sign-in you have.

Facts are drawn from court records, government reports, company statements and reputable reporting, listed below. People are named only where they were convicted, pleaded guilty or spoke publicly in an official role.