If you work in enterprise software — and especially if you’re responsible for authentication infrastructure — this has been a very uncomfortable week. The Lapsus$ hacking group, which has been on a remarkable tear over the past few months, has now confirmed breaches of both Microsoft and Okta, two of the most critical identity and access management providers in the industry.
The Okta breach is particularly alarming. Okta provides single sign-on and identity services to over 15,000 organizations. A compromise here doesn’t just affect Okta — it potentially affects every downstream customer. This is the identity provider nightmare scenario that security architects have warned about for years.
The Okta Situation#
On March 22, Lapsus$ posted screenshots on Telegram appearing to show access to Okta’s internal systems, including what looked like Okta’s Superuser/Admin portal and Slack channels. Okta’s initial response was that the breach was related to a January 2022 security incident involving a third-party contractor, Sitel (which provides customer support services for Okta), and that the impact was limited.
According to Okta’s initial statement, approximately 2.5% of their customers — roughly 375 organizations — may have been affected. The access was reportedly limited to what a support engineer could see and do, which still includes the ability to reset passwords and MFA tokens for customer accounts.
Let that sink in. A third-party support contractor’s compromised account could potentially reset authentication for hundreds of enterprise customers. This is not a theoretical attack — it happened, and the blast radius is enormous.
Microsoft’s Breach#
Microsoft confirmed that Lapsus$ gained “limited access” to their systems, with the group claiming to have exfiltrated source code from Bing, Bing Maps, and Cortana. Microsoft’s blog post (they track the group as DEV-0537) detailed the group’s tactics: social engineering, SIM swapping, and targeting personal accounts of employees to find credentials that might provide corporate access.
What strikes me about the Microsoft breach is the group’s brazenness. They posted a screenshot of what appeared to be an Azure DevOps instance containing Microsoft source code repositories while they still had access. Microsoft says they shut down the access mid-operation, and that no customer data was compromised. The leaked source code, while embarrassing, doesn’t necessarily constitute a critical security risk given that much of Microsoft’s security model doesn’t rely on source code secrecy.
The Lapsus$ Playbook#
What’s fascinating — and terrifying — about Lapsus$ is their methodology. This isn’t a nation-state APT using zero-days and custom malware. Their playbook is almost entirely based on social engineering and identity compromise:
Recruit insiders. Lapsus$ has openly advertised on Telegram for employees at target companies willing to provide VPN credentials, remote access, or other initial footholds. They reportedly pay well.
SIM swapping. By convincing mobile carriers to transfer a target’s phone number to an attacker-controlled SIM, they can intercept SMS-based MFA codes. This effectively bypasses one of the most common second-factor authentication methods.
Credential harvesting. They target personal email accounts and devices, looking for corporate credentials that employees have saved or synced outside of corporate security boundaries.
MFA fatigue attacks. Repeatedly sending MFA push notifications until the target gives up and approves one, typically in the middle of the night. I’ve seen this technique described before, but Lapsus$ appears to have operationalized it at scale.
None of these techniques are novel. But the combination, executed with speed and audacity against high-profile targets, has proven remarkably effective.
What This Means for Identity Architecture#
The Okta breach forces a reckoning with how we think about identity provider security. We’ve spent years consolidating authentication through providers like Okta, Azure AD, and Auth0, and for good reason — centralized identity management is far better than every application rolling its own auth. But centralization creates concentration risk.
A few things I’m thinking about:
Third-party access is your attack surface. Okta wasn’t breached through their core engineering team — it was through a support contractor. Every organization that provides elevated access to vendors, contractors, or support partners needs to reassess. What can those accounts see? What actions can they take? Are they monitored with the same rigor as internal privileged accounts?
SMS-based MFA is not enough. If Lapsus$ can defeat SMS MFA through SIM swapping, and push-notification MFA through fatigue attacks, we need to be moving toward phishing-resistant authenticators. FIDO2/WebAuthn security keys and platform authenticators (Windows Hello, Touch ID) are significantly harder to compromise because they’re bound to a specific origin and device.
Zero trust isn’t just a marketing term. The principle that no access should be implicitly trusted based on network location is exactly the kind of architecture that limits blast radius. Even if an attacker gets valid credentials, every access request should be evaluated based on device posture, behavioral signals, and least-privilege principles.
My Take#
I’ve been building and advising on authentication systems for a long time, and the Okta situation is a wake-up call that many of us needed. We’ve gotten comfortable treating our identity provider as a trusted black box — plug it in, enable SSO, check the compliance checkbox. But who watches the watchers?
The uncomfortable truth is that Lapsus$ isn’t doing anything technically sophisticated. They’re exploiting the human layer — the same layer we’ve always known is the weakest link. The difference is they’re doing it systematically and at scale against the providers we depend on most.
My immediate advice: audit your identity provider’s support and contractor access model. Enable FIDO2 wherever possible. Implement conditional access policies that limit what even authenticated users can do based on context. And have a response plan for the scenario where your identity provider itself is compromised — because that scenario is no longer hypothetical.
This is going to be a long year for identity security.