Last weekend, IT administrators worldwide were startled by widespread account lockouts in Microsoft Entra ID (formerly Azure Active Directory). User accounts were suddenly flagged for “leaked credentials” and automatically locked, even though there was no evidence of any actual breach. As details emerged, it became clear that a new security feature rollout – intended to protect user tokens and credentials – had backfired due to an internal error. In this post, we’ll break down what happened, the root cause of the issue, how hybrid identity environments (AD FS, Azure AD, and third-party SSO) were affected, and Microsoft’s response timeline and workarounds.
Background: New Token Protection Feature (MACE Credential Revocation)
Microsoft Entra ID includes advanced identity protection capabilities to detect compromised credentials and protect accounts. In mid-April 2025, Microsoft began rolling out a new enterprise application/feature called MACE Credential Revocation as part of Entra ID’s leaked credential detection. The goal of MACE (an internal code name) is to enhance security by automatically revoking credentials that appear compromised. In practice, it checks if a user’s credentials (e.g. password hashes) surface in breach data (like the dark web) and flags those users as high-risk. When such leaked credentials are detected, Entra ID can force a password reset or lock the account to prevent abuse, bleepingcomputer.com.
Microsoft silently added the MACE Credential Revocation app into customer tenants to deploy this capability. Many admins observed that a new Entra ID enterprise application (service principal) for MACE appeared in their tenant’s directory right around the incident time, provisioned by Microsoft’s internal processes. In other words, Microsoft “flipped a switch” globally to enable this token protection feature. Unfortunately, organizations began experiencing a flood of account lockouts almost immediately after MACE was introduced – a strong indication that something had gone wrong with the rollout.
Widespread False Positive Lockouts Over the Weekend
Late on Friday (April 18th) and Saturday, April 19th, Windows administrators from numerous organizations reported mass account lockouts triggered by Entra ID’s leaked credential alerts. Entra ID (via the new MACE app) was flagging many user accounts as compromised, claiming their credentials had been found in leaks or on the dark web. These alerts came in a torrent: one managed security provider reported over 20,000 such notifications from Microsoft overnight, affecting users across many different customer tenants. Accounts that were flagged were automatically locked out of the Entra tenant for safety, disrupting access to Azure AD-integrated applications and services.
IT pros quickly suspected these were false positives rather than genuine compromises. Many affected accounts had unique passwords not used elsewhere, were protected with multi-factor authentication, and showed no signs of suspicious activity in sign-in logs. Some organizations saw an enormous portion of their users impacted – one admin noted that about one-third of all accounts in their tenant were suddenly locked. In another case, even users who rely solely on passwordless authentication methods (with no static password to leak) were flagged as “leaked,” underscoring that this couldn’t be a normal credential breach. All evidence pointed to an internal error in Microsoft’s detection mechanism.
The Entra AD sign-in logs for impacted users showed error codes like 53003, indicating they were blocked due to a risk policy in the “home tenant.” In other words, Entra ID’s risk detection had marked the accounts as high-risk and was actively preventing their sign-ins. Administrators noted failure reasons such as “User blocked due to risk on home tenant,” corresponding to Conditional Access policies that kick in when an account is deemed compromised. This was understandably alarming – it looked exactly like a mass credential breach, except it affected too many accounts simultaneously to be believable.
The Entra ID sign-in log shows error code 53003 (“User blocked due to risk on home tenant”) for an affected account. Many organizations saw similar log entries, as Entra ID flagged numerous users as high-risk due to supposed leaked credentials bleepingcomputer.com.
Impact on Hybrid and Federated Environments (AD FS and Third-Party SSO)
This incident hit cloud-only Azure AD tenants and impacted hybrid identity setups and organizations using federation. Because the Entra ID Protection system operates at the cloud identity level, any account in the tenant could be locked out by these alerts, regardless of how the user typically authenticates. Companies using Active Directory Federation Services (AD FS) for sign-in, or those federating through third-party SSO providers (like Okta or Ping), found that their users were blocked in Entra ID just like cloud-managed accounts.
In a federated scenario, the user’s primary authentication (with AD FS or a third-party IDP) may have succeeded. Still, after that, Azure AD/Entra ID would refuse to issue tokens because the account was marked “high risk” by the new leaked credential detector. Entra ID treated these users as compromised on the Microsoft side, locking them out of all Azure AD-connected applications. This perplexed admins: on-premises AD and AD FS logs showed no issues (since the credentials weren’t truly leaked), yet Azure AD actively blocked the users. Many administrators initially scrambled to troubleshoot their AD FS or SSO systems, only to eventually learn that the problem was upstream in Entra ID’s risk engine.
Multiple reports confirm that hybrid Azure AD environments were affected. The account lockouts were a “tenant-level” action from Entra ID – even for federated users – and not due to any on-prem AD policy. One admin shared that Microsoft support identified it as a tenant lockout due to the MACE rollout, not an actual breach, allowing them to “breathe a sigh of relief”. In practical terms, this meant the cloud side of the identity (Entra ID) had decided the account was compromised and locked it, independent of the on-premises status. Organizations leveraging third-party SSO saw the same effect: their users might pass the third-party’s authentication, but then get blocked by Microsoft Entra ID’s risk-based policies. In summary, no configuration was immune – the false alerts cut across cloud-only and hybrid setups alike, since the underlying issue was within Microsoft’s global Entra ID service.
Root Cause: Token Logging Mishap and Inadvertent Credential Alerts
So what exactly went wrong with Microsoft’s new token protection feature? On Monday, April 21, Microsoft finally confirmed the root cause: an internal logging error during the MACE feature rollout led to user refresh tokens mistakenly recorded in Microsoft’s logs, which triggered Entra ID’s compromise detection. In an advisory to affected customers, Microsoft explained that on Friday, 4/18/25, they discovered that a subset of short-lived user refresh tokens (used for session continuity) were being logged in their internal systems. In contrast, only token metadata is typically logged, not the tokens themselves.
This was a significant security oversight. Storing actual auth tokens in logs is akin to accidentally leaking credentials, since tokens could be used to impersonate a user. Upon realizing the mistake, Microsoft’s team immediately corrected the logging process to stop recording tokens. They then took the prudent step of invalidating all the refresh tokens that had been logged, essentially as a precaution to “protect customers” in case any of those tokens could be accessed improperly. In theory, invalidating those tokens would force the affected users to re-authenticate (which is a minor inconvenience but ensures a potentially compromised token can’t be reused).
However, this remediation step had an unforeseen side effect. By invalidating the refresh tokens, Microsoft inadvertently triggered Entra ID’s leaked credentials alerts for those accounts, as the system interpreted the token invalidation as a sign the credentials were compromised. Microsoft Entra ID Protection automatically flagged those users as high-risk, suspecting their credentials had leaked, and generated alerts between 4:00 AM UTC and 9:00 AM UTC on April 20th for each account. In other words, Microsoft’s attempt to safeguard customers (after logging the tokens) set off a false alarm within the very security system designed to catch illicit token use. The result was a wave of “leaked credentials” detections across many tenants, corresponding to accounts whose refresh tokens had been invalidated.
The “short-lived” refresh tokens mentioned in Microsoft’s advisory likely relate to tokens issued under newer security enhancements (such as continuous access evaluation or token protection measures). Only a small percentage of users had these specific tokens, which is why not every Entra ID user was impacted, but in some organizations, it was still a large chunk of accounts. Microsoft emphasized that they do not indicate unauthorized access or real-world credential compromise in this incident. The alerts and lockouts directly resulted from the internal token logging mishap, not a breach by any threat actor. In essence, the security feature over-rotated – it treated Microsoft’s internal error as an external credential leak.
Microsoft’s Response and Timeline of Events
Timeline of the incident: According to Microsoft’s report, the sequence began on Friday, April 18, 2025, when they identified the flawed internal logging behaviour (capturing real refresh tokens). The logging was fixed that same day, and the team invalidated the affected tokens. The next wave of activity came in the early hours of Sunday, April 20, 2025 (UTC), when Entra ID Protection automatically issued the leaked credential alerts due to those token invalidations. Over that weekend (April 19-20), administrators worldwide noticed the high-risk user alerts and account lockouts popping up en masse.
Initially, Microsoft did not make a public announcement, and the Azure/Entra service health dashboard did not reflect this issue in many tenants. This left IT admins scrambling for information. Many opened support cases with Microsoft. Early communications from support were somewhat inconsistent – some admins were informed of the new MACE Credential Revocation rollout being the cause (essentially the correct explanation). In contrast, others were erroneously told it might be related to an outage in their region (despite no such outage being reported). This response disparity likely stemmed from support teams investigating in real-time before the root cause was confirmed internally.
By Monday, April 21, 2025, Microsoft had completed its investigation enough to confirm the actual cause and began communicating details to customers. An advisory from Microsoft (later shared publicly) admitted the mistake of logging refresh tokens and explained the inadvertent alerts, as quoted above. Microsoft clarified that the Entra ID “leaked credentials” alerts over the weekend were false positives triggered by their internal cleanup procedure, not due to any new breach of user passwords. In the same communication, Microsoft assured customers that if any evidence of actual unauthorized access to those tokens is found, they would initiate their normal security incident response – but so far, none has been detected.
Interim Workarounds: As the incident unfolded, Microsoft provided guidance on how administrators could restore access for users locked out by these false alerts. The primary method was to use the “Confirm User Safe” feature in Microsoft Entra ID Protection. Marking a flagged account as safe tells Entra ID that the risk alert was a false positive or otherwise addressed, which lowers the user’s risk level and automatically re-enables their account. Microsoft directed admins to review the “Risk last updated” timestamp on the alert and only confirm safe for those impacted users during the known incident window (to avoid accidentally dismissing any legitimate alerts). In practice, many admins could quickly unlock their users by bulk-confirming the safety of all accounts caught up in the 4/20 alert surge.
Another mitigation path was to perform a password reset for the affected users. Changing a user’s password will invalidate their existing refresh tokens and clear the “leaked credential” risk flag (since the potentially compromised credential – the old password – is no longer in use). Several organizations chose this route for users urgently needing access, especially if they didn’t immediately realize the scope of the false positive issue. Between marking users as safe and forcing password resets, most organizations had unblocked their users by the end of the weekend or early Monday.
Microsoft has stated it will publish a formal Post Incident Review (PIR) once the internal investigation is complete. This PIR report will be shared with affected customers and will likely detail the exact timeline, root cause analysis, and improvements to prevent such a mishap. As of this writing, that report is pending, but Microsoft’s quick admission of fault and the details already provided give a clear picture of the scenario.
Conclusion
The Entra ID lockout incident is a potent reminder that even well-intentioned security features can have unintended consequences if not carefully implemented. In this case, Microsoft’s new token protection mechanism (MACE) was designed to proactively safeguard accounts by catching leaked credentials. Still, an internal error caused it to treat Microsoft’s actions as a threat. Thousands of users across many organizations were needlessly locked out of their accounts for several hours, illustrating the ripple effect in hybrid identity systems – a change in the cloud can suddenly impact on-premises and federated users globally.
The good news is that no actual breach occurred, and Microsoft swiftly corrected the error once it was identified. Administrators also quickly leveraged Entra ID’s tools (like confirming users as safe) to get users back to work. Microsoft has acknowledged the issue and will be learning from it, likely improving their rollout processes and safeguards around token logging. For IT professionals, this event is a case study in the importance of monitoring cloud service changes: a new feature introduced by your vendor can sometimes have organization-wide effects overnight. In the words of one Microsoft advisory during this incident, “we inadvertently generated alerts…indicating the user’s credentials may have been compromised,” bleepingcomputer.com – a candid admission that, in this instance, the cause of the scare was the defender, not an attacker.
In the future, Microsoft Entra ID’s leaked credential detection remains a valuable security feature, and with the token logging mistake resolved, it should operate as intended – quietly protecting users in the background. This incident will be remembered for its broad reach and clear communication with Microsoft. As always, staying informed through official channels and community forums can help IT pros navigate such surprises. This time, a tough weekend for admins ended with relief that it was “just a drill” caused by a tool malfunction, not an absolute security nightmare.
Dave Kawula – MVP
