Microsoft resolved a service incident on June 1, 2026, that left thousands of users unable to reach the My Sign-Ins portal, blocking multifactor authentication (MFA) setup and management of sign-in methods. The outage, tracked as MO1329260 in the Microsoft 365 admin center, caused intermittent HTTP 504 Gateway Timeout errors for about four hours, disrupting identity workflows for businesses that depend on Entra ID (formerly Azure Active Directory).

Users first reported issues at approximately 10:00 AM UTC, when attempts to access https://mysignins.microsoft.com returned blank pages or 504 errors. The portal serves as the central hub for viewing sign-in activity and configuring MFA methods—critical actions for security hygiene and onboarding. Without it, new employees couldn’t enroll in MFA, and existing users struggled to update expired phone numbers or switch authenticator apps. The impact quickly rippled through organizations that enforce MFA via Conditional Access policies, as any user whose session required re-authentication or security info verification was effectively deadlocked.

Microsoft acknowledged the problem in a service health advisory at 10:45 AM UTC, stating: “We’re investigating an issue where users may be unable to access the My Sign-Ins portal. Affected users may see 504 errors when attempting to navigate to the site or manage security info.” The advisory confirmed that other Microsoft 365 services—Exchange Online, SharePoint, Teams—remained operational, isolating the incident to the identity backend. By 12:30 PM UTC, the company had identified a recent configuration change in Entra ID’s frontend proxy layer as the likely culprit and began rolling it back. Full recovery was declared at 2:15 PM UTC, though some users experienced residual delays until 3:00 PM.

What Actually Broke?

The My Sign-Ins portal relies on a set of microservices within Entra ID that handle authentication method registration, security info updates, and sign-in activity logs. On June 1, a change intended to optimize traffic routing inadvertently misconfigured the backend connection limits, causing the proxy to time out under normal load. The 504 errors surfaced when the gateway waited too long for a response from the identity service, which was overwhelmed by connection attempts that couldn’t be properly distributed. Microsoft’s incident report, published 24 hours later, cited “a configuration error in an upstream proxy component” and noted that the rollback resolved the issue within 30 minutes of implementation.

While the root cause seems mundane, the blast radius was significant. The portal’s deep integration with MFA setup meant that any user who needed to change their phone number, set up a new authenticator app, or perform a self-service password reset (when combined with MFA) hit a wall. Even MSPs using delegated administration to manage client tenants found themselves unable to access customer My Sign-Ins settings, complicating bulk user management.

User Impact: More Than Just an Inconvenience

For IT admins, the outage wasn’t merely a portal glitch—it was a security event. MFA is the front line of defense against account compromise, and 99% of Microsoft’s own breaches originate from accounts without MFA, according to the company’s security research. When the enrollment path disappears, new hires can’t comply with mandatory MFA policies, creating a pileup of unprotected accounts. Organizations with strict compliance requirements—healthcare under HIPAA, finance under PCI DSS—faced potential audit risks if new accounts remained without MFA longer than a few hours.

Real-world consequences emerged quickly on social media and admin forums. One sysadmin reported that a batch of 50 new interns scheduled for onboarding Monday morning couldn’t complete MFA registration, delaying their access to company resources until the incident resolved. Another noted that a VIP user’s password reset attempt—triggered by a suspicious login—required an MFA update, but the portal was down, forcing the admin to temporarily disable MFA (a security no-no) to restore access. Microsoft’s official channel for these incidents, the Microsoft 365 Service Health Dashboard (SHD), remained accurate throughout, but the lag between first user reports and the SHD update—about 45 minutes—felt like an eternity for those troubleshooting.

The Identity Backbone Under Strain

This isn’t the first time Entra ID has buckled under a seemingly small change. In March 2024, a worldwide authentication outage (MO821616) locked users out of all Microsoft 365 services for over three hours because a router configuration change caused token signing failures. In October 2023, an Azure DevOps incident spilled into Entra ID, disrupting MFA prompts for millions. Each occurrence underscores the fragility of centralized identity services. When every application—Office, Teams, third-party SAML apps—relies on a single token issuer, a hiccup in the proxy layer can cascade into a business-stopping event.

Yet, Microsoft’s identity platform has evolved to be remarkably resilient. The company recently introduced continuous access evaluation (CAE), which reduces reliance on token lifetime and can revoke sessions in near real-time. It also pushed out Temporary Access Pass (TAP) in 2022, a time-based one-time code that can bootstrap MFA setup without the self-service portal. Admins who had adopted TAP as a backup pathway were able to scaffold MFA for critical users during the June 1 incident. But adoption remains low—many organizations still rely on the default self-service flow, leaving them exposed when that flow breaks.

What IT Admins Can Do Right Now

  1. Provision Temporary Access Pass for emergency onboarding. TAP is configurable via Entra ID authentication methods policies and can be set for one-time use with short validity (e.g., 30 minutes). Create a few TAPs for high-priority users before the next identity hiccup.
  2. Diversify MFA methods. Encourage users to register multiple authentication methods—phone, authenticator app, FIDO2 key—so that if one method requires an update and the portal is down, another might still work. Microsoft Authenticator supports passwordless phone sign-in, which is more resilient to backend outages because the token is device-bound.
  3. Use the Microsoft 365 Service Communications API. Programmatically ingest service health alerts to trigger internal automation. For instance, if an identity advisory is posted, your ticketing system can auto-acknowledge and notify help desk staff to prepare for MFA-related tickets.
  4. Pre-register MFA for all users immediately. The default “14-day grace period” for new users can be dangerous. With zero-touch provisioning tools like Microsoft Entra ID Governance, you can force MFA registration during the first sign-in or via a pre-provisioning app. That way, the My Sign-Ins portal is only needed for changes, not initial setup.
  5. Monitor with canary accounts. Set up a synthetic user that periodically attempts to access My Sign-Ins and alerts you via Azure Monitor when a 504 appears. This gives you a head start before users scream.

The Road Ahead

Microsoft’s communication around MO1329260 was transparent and timely by historical standards, but the incident reinforces that self-service identity portals are not immune to the same operational risks as any other cloud service. As MFA becomes ubiquitous—driven by Microsoft’s own defaults and regulatory mandates—the availability of the enrollment and management experience becomes just as critical as the authentication endpoint itself. Analysts at Gartner have long warned that identity fails open too often; organizations must design their IAM flows to degrade gracefully.

For its part, Microsoft is investing in making Entra ID more resilient. The company’s internal “Auto” initiative aims to decentralize critical identity microservices, allowing them to survive partial outages. Features like delegated MFA registration via API (still in private preview) could one day let admins bypass the portal entirely. But until these land in production, incidents like MO1329260 will remain a recurring nightmare for IT teams that haven’t implemented workarounds.

The next time the My Sign-Ins portal throws a 504, the difference between a minor bump and a security incident will hinge on whether admins have a plan B. That plan B should not involve disabling MFA.