The Okta breach: what happens when your identity provider is compromised
A look at the Okta incident in October 2023 and practical conclusions for companies that rely on centralised authentication.
In October 2023 Okta disclosed an incident: attackers gained access to its customer support system and through it were able to view files associated with accounts of some customers. This is not the first time Okta has had security problems - a similar incident occurred through a contractor in 2022.
For companies using Okta or similar single sign-on (SSO) systems, this incident raises several important questions. Not specifically about Okta - but about what your dependency on an identity provider looks like in general.
Why an identity provider is a special dependency
Centralised authentication is enormous operational value. One account for all systems, unified access management, the ability to instantly revoke a departing employee's access. This works well.
But there is a flip side. The identity provider is the point through which access to everything passes. If it is compromised - it is not individual systems that are at risk, but the entire infrastructure. This is not hypothetical - exactly this happened with several Okta customers in 2022: through a compromised contractor account, attackers gained the ability to affect customer environments.
The more centralised the access management, the higher the operational efficiency - and the higher the cost of a compromise at the centre.
What specifically happened in October 2023
According to Okta, attackers gained access to its customer support system. Through this system, support staff have access to customer files for diagnosing problems - in particular, HTTP Archive (HAR) files that customers submit when opening support tickets. HAR files can contain session cookies and other sensitive data.
A number of Okta customers were notified that their files had been viewed. Several large companies - BeyondTrust, Cloudflare, 1Password - publicly confirmed they had detected suspicious activity related to the incident.
Practical questions for leadership
An incident at a provider is something you do not control. But there are things within your own responsibility.
Privileged accounts must be protected more strongly. Administrative accounts in an SSO provider are not just another corporate login. They need separate protection: unique passwords, hardware second factor, a minimal circle of people with access.
What happens if the identity provider becomes unavailable? This is not paranoia - it is a business continuity question. If Okta goes down or is compromised, how do employees access critical systems? Are there fallback mechanisms?
Logging and anomaly detection. Unusual logins, access attempts from atypical locations, bulk access requests - all of these should generate alerts. If incidents at the provider do not show up in your monitoring - that is a blind spot.
What do you submit to vendor support systems? The HAR files at the centre of this incident are an example of how auxiliary channels can contain sensitive data. The policy of what gets shared with vendor support deserves explicit attention.
A minimum-readiness checklist
- Do administrative accounts in the SSO provider have a hardware second factor?
- Is the list of people with access to the administrative console restricted?
- Is there an access log for administrative functions with alerts on anomalies?
- Is there a response plan for unavailability or compromise of the provider?
- Do you know what data about your environment is accessible to the vendor's support team?
No provider is immune to an incident. The question is how clearly your dependencies on it are visible to you, and how prepared you are for how events might unfold.