Another “Azure Breach”? Not Really. It Was Almost Certainly an Identity Breach.
Every few weeks another headline appears suggesting that a major cloud platform has been breached. This week, the alleged victims include household names such as McDonald’s, Vodafone, Kyndryl, Gap, Wyndham, and others, with millions of Azure and Entra directory records reportedly being offered for sale by a threat actor calling themselves “TheHatman.”
But based on what has been reported so far, there is no indication that Microsoft Azure itself was compromised. The far more likely explanation is much simpler and much more important for enterprise security leaders to understand: someone obtained legitimate access and logged in.
That distinction matters because it reflects how modern breaches increasingly occur. Attackers do not necessarily defeat firewalls, exploit exotic vulnerabilities, or “hack the cloud.” They steal or manipulate identity. Once they possess a legitimate Azure or Entra identity, they are often using Microsoft services exactly as they were designed to be used. The infrastructure is functioning normally. The problem is that the person being authenticated is not who the organization thinks they are.
The available reporting points toward compromised identities rather than compromised Azure infrastructure. Security researchers examining leaked samples have described what appear to be legitimate Azure Active Directory exports. Possible paths include stolen credentials, phishing, infostealer malware, compromised browser sessions, social engineering, or abuse of authentication recovery processes. The precise entry point has not yet been publicly established, so it would be irresponsible to claim one specific technique with certainty.
What we can say is that the attack pattern is extremely familiar. An employee may enter credentials into a convincing phishing site. Malware may harvest stored credentials or session tokens from a browser. A help desk employee may be socially engineered into resetting an account. An attacker may exploit a weak recovery workflow. In some cases, a real time adversary in the middle attack can proxy the authentication process and convince a legitimate employee to help authenticate the attacker.
This is why identity has become the front door of the enterprise. Attackers have learned that stealing an identity is frequently easier than attacking the infrastructure behind it. Once an attacker is recognized as a legitimate employee, many of the expensive security systems protecting the network are already operating at a disadvantage.
Traditional MFA does not automatically solve this problem. SMS codes can be intercepted or socially engineered from users. Authenticator app codes can be relayed during real time phishing attacks. Push notifications can be approved by employees who believe they are responding to a legitimate login request. Help desks can be manipulated into resetting authentication methods entirely. In these scenarios, the attacker does not technically defeat MFA. They convince the legitimate user or support organization to complete the authentication process for them.
Passkeys are an improvement over passwords and traditional MFA. Properly implemented biometric FIDO2 credentials provide strong resistance to conventional phishing because the authentication credential is cryptographically bound to the legitimate web origin. That is an important advancement and one the industry should continue to embrace.
However, not every passkey deployment provides the same level of identity assurance. Most passkeys are synchronized through consumer cloud ecosystems and reside on multipurpose devices that contain applications, operating systems, browsers, communications tools, and recovery mechanisms. Enterprise security therefore depends not only on the cryptographic credential itself, but also on the security of the surrounding device, cloud account, recovery workflow, enrollment process, and authentication policy. And unfortunately, some 39 unique compromises of passkeys have been identified with many in the wild.
This is an important distinction. The problem is not that FIDO2 is broken. It is that organizations sometimes treat “we deployed passkeys” as equivalent to proving the identity of the human being requesting access. Those are not necessarily the same thing.
This is exactly where Token takes a different approach. Token combines FIDO2 cryptography with dedicated hardware, fingerprint based biometric identity, origin binding, and physical proximity. The credential remains inside a dedicated secure hardware device rather than being synchronized among consumer devices or cloud accounts. Authentication requires the authorized user’s fingerprint. The credential is cryptographically associated with the legitimate domain. And the Token device must be physically near the system being accessed.
That combination removes many of the mechanisms attackers rely upon. There is no SMS code to steal, no authenticator app code to relay, and no push notification that an employee can be persuaded to approve. Stolen usernames and passwords become substantially less valuable because possession of those credentials alone cannot complete authentication.
Even if an attacker successfully convinced an employee to visit a fake login page, Token’s FIDO2 origin binding would prevent the authenticator from completing authentication for the attacker’s domain. Even if the attacker knew the employee’s username and password, the attacker would still lack the registered hardware device and the authorized fingerprint required to use it. Even compromising a cloud synchronization account would not produce a copy of the Token credential because the private credential remains inside the dedicated Token hardware.
This is why Token would have stopped the type of identity attack that appears most consistent with the available evidence in this campaign. The attacker could still send the phishing email. The employee could still click the link. The attacker could still possess a stolen password. But the authentication chain would terminate before access was granted.
The larger question raised by incidents like this is therefore not simply whether Azure was breached. Based on the evidence available today, it probably was not.
The more important question is why so many enterprises continue to spend extraordinary amounts of money detecting attackers after they enter the network while comparatively little attention is given to making the initial identity compromise extraordinarily difficult.
Organizations have invested billions in firewalls, endpoint detection, network monitoring, SIEM platforms, threat intelligence, and incident response. All of those technologies remain important. But they operate downstream from the front door. If an attacker can successfully authenticate as an employee, the security team is immediately forced into the much harder job of determining whether an apparently legitimate user is actually an adversary.
Dedicated hardware biometric identity changes that equation. Instead of asking whether the person knows the right password, possesses the right phone, can obtain the right code, or can convince someone to approve a prompt, the system requires cryptographic proof tied to a specific physical authenticator and a fingerprint based biometric identity.
That is the lesson enterprises should take from this campaign. Attackers are not necessarily breaking into Azure. Increasingly, they are logging in. And the most effective place to stop them is before the front door ever opens.
