Someone was asking me just how many times Okta has been breached recently. Upon looking around I realized there isn’t a simple place to answer such a question.

Is there? On November 29, 2023 Okta published their “October Customer Support Security Incident” but it doesn’t link to any list of previous incidents. Notably, Okta’s official “security advisories” doesn’t seem to include breaches of Okta.

Here’s a few easy examples rattling around the web:

• Nov 2023: “Okta security breach much worse than originally disclosed – all customers’ data potentially affected”
• Nov 2023: “Okta tells 5,000 of its own staff that their data was accessed in third-party breach”
• Sep 2023: “4 Okta customers compromised in social engineering attacks”
• Dec 2022: “Okta confirms another breach after hackers steal source code”, its “fourth breach of the year“.
• Mar 2022: “Okta says 366 customers potentially affected in data breach” where “‘Two Months Is Too Long’: Tenable CEO Slams Okta’s Breach Response”
• Oct 2019: “Okta SRE Pleads Guilty to Stealing IDs to Violate Women’s Privacy [before being hired by Okta]”

And then of course, I have to add in for good measure:

• Aug 2011: “Cloud security different, says Okta”

I wrote that warning in 2011 and here we are twelve long years later looking at the results. Customer Identity and Access Management (CIAM) is now a market segment rife with risks associated with their use:

1. CIAM are attractive targets for attack. Proprietary and “exit-barrier” providers become especially juicy targets as they expect to get away with low safety in proportion to how hard they can make it for their customers to leave them.
2. CIAM can be overly centralized in a way that impacts an entire user access ecosystem, challenging availability architectures that depend on “blast radius” concepts and data boundaries.

Short list, I know.

But let’s be honest here and say what has been true for more than a decade: If you have “unusual” behavior exploiting your CIAM it’s going to come down to usual observations such as where a user is coming from, whether a string of failures concludes with any success (e.g. brute force versus fat-finger events), and how much authorization longevity or reuse is going on (e.g. same session ID with a rotating user agent or different origins).

Okta should publish all their breach reports in one place with all the explanations.