The Okta breach: what it means when an identity provider is compromised

In March 2022, the Lapsus$ group published screenshots indicating access to Okta's internal systems. Okta is one of the largest providers of identity and access management systems, used by thousands of companies for single sign-on to corporate applications.

The incident was confirmed. Okta reported that the breach involved a support contractor's account and that approximately 2.5% of customers were potentially affected.

For security specialists, this incident raised questions about the supply chain, contractor access management, and incident response procedures. For managers, it raised a different question: what happens to my company if the people I have delegated access management to are compromised?

What an identity provider is and why it matters

When your employees sign into work applications through a single account, that is SSO - single sign-on. The identity provider is the system that verifies who you are and issues access tokens to all the other services.

This is very convenient. One account instead of dozens of passwords. Centralised management: when an employee leaves, you revoke access in one place. This is the right architecture.

But it creates a concentration of risk. Whoever controls the identity provider potentially controls access to all the services connected to it. The Okta breach showed that this risk is not abstract.

Three levels of questions after the incident

The first level is operational. How will you know if your identity provider is compromised? Do you have monitoring for anomalous account behaviour? Can you quickly block suspicious sessions?

The second level is architectural. Do all your systems flow through a single identity provider? Do you have the ability to temporarily fall back to an alternative authentication procedure if the primary provider is unavailable or compromised?

The third level is contractual and audit-related. What is your identity provider required to tell you in the event of an incident, and within what timeframe? How does it manage access for its own contractors - the people who maintain the system that manages your access?

What changed in identity management after this incident

The incident sharpened several requirements for choosing and configuring identity providers:

• multi-factor authentication must apply not only to end users but also to the provider's administrative accounts;
• contractor and support staff access to identity management systems must be strictly limited by the principle of least privilege;
• client companies should have independent logs of anomalous behaviour, rather than relying solely on the provider's own logs.

These are not new principles. But Okta turned them from theory into a concrete reason to check.

Questions for a director

1. Do you know which systems in your company are connected to the identity provider?
2. Do you have a procedure for responding to a provider compromise?
3. How would you find out about a suspicious sign-in that happened overnight?
4. Do your most important systems have an additional layer of protection beyond SSO, or is the identity provider the only barrier?

Incidents like Okta show that infrastructure security cannot be fully delegated to a third party. You delegate the operational work, but not the responsibility for understanding the risks.