Okta and Uber Breaches: Identity Providers as Single Points of Failure

In the space of a week, a teenager walked into one of the world's largest technology companies and then, days later, into a games publisher, taking a substantial quantity of unreleased material with them. In the first case the entry was a contractor's credentials bought from an underground market, followed by a stream of authentication prompts and a message claiming to be from the internal technology team. The contractor eventually approved one. That is a very old technique. What makes this month instructive is not how the attacker got in, but what a single accepted prompt turned out to be worth.

Federation concentrated the value and nobody re-rated the asset

Centralising authentication was the right decision. One strong credential, one place to revoke it, one audit trail, consistent policy across a hundred applications: every one of those is a genuine security improvement over a password per system. The cost of that decision is that the identity provider now holds the keys to everything federated behind it. Compromise is lateral by default rather than by effort. And because federation issues sessions, an attacker holding a valid session token often does not need to authenticate again at all — which is why the question of how long your sessions live is now a more important control than the strength of your password policy. Most organisations still run their identity platform as an information technology service with a service-desk queue, rather than as the single most consequential system in the estate. That classification is the underlying problem.

Three different identity failures, all in the same year

Compromise the provider's vendor. In January, attackers reached a support engineer's workstation at an outsourced provider serving a major identity vendor. The vendor's eventual assessment reduced the impact substantially from early estimates, but the structural point stands: your identity provider's support supply chain is part of your attack surface, and you almost certainly have not reviewed it. Phish the provider's users at scale. The campaign publicised last month used text messages and convincing fake login pages to harvest credentials and one-time codes from staff at well over a hundred organisations, relaying them to the real login page in real time. Multi-factor authentication was present. It simply was not the kind that resists relay. Compromise one person and ride the session. This month's intrusion needed no vendor compromise and no clever tooling. It needed one tired contractor and a prompt with an approve button.

Single sign-on did not remove your passwords. It hid them in scripts

The detail worth dwelling on in this month's incident is what happened after entry. The attacker reportedly found administrative credentials for a privileged access management system hardcoded in a script on an internal network share. One accepted push notification became administrative reach across the estate because the secrets that federation was supposed to eliminate were still lying around behind it. This is the near-universal condition. Automation accounts, service credentials, integration keys, database passwords and deployment secrets live in scripts, shared drives, wiki pages, build variables and configuration files, because none of them ever went through the single sign-on migration. Identity maturity is usually measured at the front door. The exposure is in the corridor. A credential-sprawl sweep — scanning shares, repositories and pipelines for embedded secrets, then moving them into a vault with rotation — is unglamorous, well understood, and the single highest-value follow-up to this month's news.

Make the prompt un-spammable

Push fatigue is a design flaw, not a user failing. A prompt that says only approve or deny, offers no context, and can be resent indefinitely will eventually be approved by someone at the wrong hour. Four changes, in order of value: Require number matching or equivalent challenge-response, so approving requires reading something from the legitimate login screen. Rate-limit and lock out after repeated denials, because twelve prompts in four minutes is not a user behaviour. Show context in the prompt — application, location, device — and make mismatch visible. Treat repeated denials as a security signal that pages someone, not as noise. In almost every published case this year, the pattern was visible in the logs before anything else happened.

Assume the identity provider is compromised, then look at the room

Run the exercise properly, with the platform team and the incident responders in the room, and answer six questions in writing. What can we still do if the identity platform is untrustworthy? How do we invalidate every session globally, and how long does it take? Which administrative accounts are separate from daily-use accounts, and are they phishing-resistant? Which actions require re-authentication rather than an existing session? What is our break-glass path, where are those credentials, and when were they last tested? And who at the vendor can act as one of our users, under what controls, with what logging visible to us? The last one belongs in procurement as much as in security. Ask prospective and incumbent identity vendors whether support is outsourced and to where, what administrative access their staff hold, what vendor-side access logging you receive, how quickly they will notify you of an incident affecting your tenant, and what specifically changed after their most recent one. Written answers, in the contract where possible.

Practical Guidance for Identity Infrastructure Review

• Reclassify the identity platform as your most critical system, with the change control and monitoring that implies.
• Enable number matching and denial lockout across the estate this quarter.
• Sweep for embedded secrets in shares, repositories and pipelines, then vault and rotate them.
• Separate administrative identities from daily accounts and give administrators phishing-resistant factors.
• Shorten session lifetimes for sensitive applications and confirm you can revoke all sessions in minutes.
• Ingest identity logs into monitoring and alert on repeated denials, impossible travel and new device registrations.
• Review the provider's support supply chain and put notification timing in the contract.
• Test the break-glass path on a schedule, with the platform team absent.

The Regional Angle

Three regional conditions change the risk calculation here. The first is that regional groups rarely have one identity estate. They have one brand and eight to forty legal entities, several of which were acquired, each arriving with its own directory, its own administrators and its own licensing decision made by whoever ran technology at that company. Federation between them is usually partial, trust relationships were configured to solve a specific problem years ago, and the group security function has visibility into perhaps half. An attacker does not need the well-run head-office tenant. They need the trading subsidiary with three administrators, no conditional access policy and a shared account for the warehouse system — and then they need the trust relationship that someone configured in 2019 and nobody has looked at since. Map the trusts before hardening the primary tenant; the map itself is usually the finding. The second is a two-speed identity estate created by regulation. Banking, insurance and government-adjacent entities here frequently cannot adopt the global identity platform the rest of the group uses, because directory content and authentication logs would sit outside the country and the regulator's expectations on hosting are explicit. So those entities run an older on-premises identity stack, often without modern conditional access, adaptive policy, or the number-matching capability being recommended everywhere this month. The result is perverse: the entity holding the most sensitive data runs the weakest identity controls, and it is the one least able to adopt the fix. The honest response is to treat that as a known, documented gap with compensating controls — tighter network segmentation, hardware factors for administrators, shorter sessions, heavier logging — rather than pretending the group standard applies. The third is monitoring scope. Many organisations here buy detection and response from a managed provider, under a contract scoped years ago around firewalls, servers and endpoints. Identity telemetry is frequently not in that scope at all, which means the pattern that preceded every publicised intrusion this year — a burst of denied prompts, an unusual device registration, a sign-in from an unexpected country — arrives in a log nobody is watching. Renegotiating the monitored scope to include identity events is the cheapest meaningful control available to most regional organisations right now, and it is a commercial conversation rather than a technical project.

The objection worth taking seriously

The strongest objection is that this whole discussion invites the wrong conclusion. Federated identity is dramatically safer than the alternative, and the response to a single point of failure is not to fragment authentication into dozens of weaker ones. Nor is this month's incident really an identity-provider story: the entry was a contractor's stolen credential and a fatigued human, and the escalation was a hardcoded password in a script — neither of which implicates the identity platform at all. Reading these events as an argument against centralised identity would leave organisations measurably worse off. That is correct, and it should be said clearly in any board briefing that follows this news. But the recommendation here is not fragmentation. It is that the asset has been re-rated by events and the controls have not moved with it. Tier-zero systems get separated administration, phishing-resistant factors, session control, dedicated monitoring, tested recovery and supplier scrutiny. Most identity platforms get a service desk and a quarterly access review. And the escalation detail strengthens rather than weakens the case: the identity boundary held exactly as far as the secrets lying around behind it, which is the part of the estate that single sign-on programmes never finish.

Common Questions

Should we move administrators to hardware keys?

Yes, and start there rather than with the whole population. The administrative group is small, the cost is trivial, and it removes the technique that worked in every publicised case this year.

Does shortening sessions hurt productivity?

Measurably, if applied uniformly. Apply short sessions and step-up re-authentication to sensitive applications and privileged actions, and leave ordinary work alone.

How do we assess our identity vendor's own security?

Ask about support outsourcing, impersonation capability, vendor-side access logging and notification timing, and read their last incident report rather than their certification list.

What should we expect over the next twelve months?

Expect number matching to become the default rather than an option, and expect vendors to enforce it. Expect more attacks aimed at the support and outsourcing layer behind identity providers, because it is the softest path to the hardest target. Expect session-token theft to become the dominant technique as multi-factor coverage improves, which shifts the defensive conversation from authentication to session management. Expect customers, insurers and regulated counterparties to start asking specifically whether administrators use phishing-resistant factors. And expect the pattern of very young, socially fluent attackers to continue, because arrests over the past six months have not slowed it.

---

Identity Infrastructure Review — we map the trust relationships between your entity tenants, test whether you can invalidate every session in minutes, and find the credentials still sitting in scripts behind your single sign-on.