Microsoft MFA Outage Hits MySignIns Portal and Setup Flows

Microsoft confirmed on June 1, 2026 that a service outage is stopping some users from setting up multi-factor authentication (MFA, a second login check beyond a password) or reaching the self-service portal at mysignins.microsoft.com. The company is tracking the disruption as incident MO1329260 and says it has failed over to backup infrastructure while it monitors recovery.

The locked portal is the visible symptom. For organizations that run Conditional Access policies requiring MFA registration, the same fault can ripple downstream and shut new or re-registering users out of Microsoft 365 services entirely, because the security layer meant to protect them cannot finish its own setup step.

What Microsoft Confirmed About the MFA Portal Outage

The acknowledgment came through the Microsoft 365 Status account on X, the company’s official channel for live service notices. It pointed administrators to the incident record inside the Microsoft 365 Admin Center for status and remediation guidance.

We’re investigating an issue where some users may be unable to setup MFA or access the mysignins.microsoft.com website. For more information, please see MO1329260 in the admin center.

That statement was posted by the Microsoft 365 Status team on June 1, 2026. A follow-up note said the company had completed a failover to alternate healthy infrastructure to mitigate the impact and was watching service telemetry to confirm full recovery.

Microsoft has not published a root cause or an estimated time to resolution. The company typically releases a post-incident review after a significant disruption clears, and those reviews land in the Admin Center rather than on any public status page.

Why a Sign-In Portal Outage Becomes a Conditional Access Problem

A broken enrollment page sounds like a helpdesk annoyance. The reason it carries weight is that the portal sits on the same identity plumbing that decides who gets into email, Teams, and SharePoint every morning.

What the Backup Service Keeps Running

When the primary sign-in service stumbles, the Microsoft Entra Backup Authentication Service steps in and reissues access tokens for sessions that are already active. Microsoft states that reauthentications for existing sessions account for more than 90% of authentications to Entra ID, which is why most signed-in employees never notice an outage at all.

The catch is written plainly in Microsoft’s own documentation. The backup service does not support new sessions or authentications by guest users. Anyone trying to start fresh, or finish a security-info registration, depends on the primary service that the current incident has knocked sideways.

Where New Sessions Fall Through

During an outage the backup service cannot evaluate every Conditional Access condition in real time, so it leans on a setting called resilience defaults to decide borderline cases using data captured at the start of a session. New sign-ins have no such session history to lean on. The table below maps how access is granted, drawn from Microsoft’s Conditional Access resilience defaults documentation.

Read the top row again. A user who needs a brand new session, and who has to pass through an MFA gate to get one, is the exact profile the portal outage hurts most.

The Users Most Exposed During the Window

Not everyone feels this equally. Employees with live, recently authenticated sessions will mostly keep working. The pain concentrates on a narrow set of accounts that all share one trait: they need to touch the registration flow right now.

• New hires onboarding today, who must register an authentication method before any Conditional Access policy will let them reach Microsoft 365.
• Existing staff re-registering or resetting MFA methods, for example after a lost or replaced phone, who route through the same mysignins.microsoft.com path.
• Guest and external users, who the backup service explicitly does not cover even for existing access.
• Accounts governed by a Conditional Access policy that forces security-info registration, where an incomplete enrollment leaves the user blocked rather than merely inconvenienced.

For a large enterprise mid-week, that is not a rounding error. A single morning of onboarding, password resets, and device swaps can stack up hundreds of users who cannot get past the front door until the registration service returns.

A Pattern of MFA Disruptions as Mandatory Enforcement Tightens

This is not the first time Microsoft’s authentication front end has wobbled, and the stakes keep climbing because the company is making MFA non-optional. The sequence of publicly reported incidents shows how routine these stumbles have become.

1. October 15, 2024: Microsoft begins requiring MFA to sign in to the Azure portal, the Microsoft Entra admin center, and the Intune admin center, the opening phase of its mandatory multifactor authentication rollout.
2. January 13, 2025: an MFA disruption built on 504 gateway timeout errors during the authentication challenge is resolved, after locking out users behind Conditional Access and MFA-gated VPNs.
3. June 2025: users across Europe, the Middle East, Africa, and Asia Pacific hit errors registering authentication methods in MySignIns, again tied to a change meant to improve MFA.
4. February 23, 2026: a fresh wave of 504 gateway timeouts under incident MO1237461 blocks US users from email, Teams, and SharePoint.

Each episode lands on the same paradox. The control that organizations are told to make mandatory becomes a single point of failure when its own infrastructure trips, and the tighter the enforcement, the fewer fallback paths a locked-out user has.

Steps for Administrators While the Service Recovers

The instinct to loosen MFA during an outage is the wrong reflex, because it trades a temporary access problem for a real security gap. There are calmer moves that keep people productive without dropping the guardrails.

Start in Service Health inside the Microsoft 365 Admin Center and pin incident MO1329260 so the team works from one source of truth instead of scattered helpdesk tickets. Confirm that resilience defaults are still enabled on Conditional Access policies, since Microsoft enables them automatically and recommends leaving them on to extend existing sessions through an outage. Where onboarding genuinely cannot wait, scope a narrow, time-boxed exclusion to the specific affected users rather than disabling MFA registration tenant-wide.

The deeper fix is structural. Microsoft’s emergency access account guidance recommends keeping two or more break-glass accounts, cloud-only on the onmicrosoft.com domain, secured with FIDO2 (a phishing-resistant passkey standard) rather than the same method as daily admin logins, and excluded from Conditional Access policies that block sign-in. Validating those accounts every 90 days is what separates a recoverable outage from a tenant nobody can administer. If this window closes cleanly within hours, most tenants will log it as noise; if it stretches across a full onboarding day, the organizations without a tested break-glass path are the ones that will be writing their own post-incident review.

Frequently Asked Questions

What is incident MO1329260?

MO1329260 is the tracking code Microsoft assigned to the June 1, 2026 outage affecting MFA setup and the mysignins.microsoft.com self-service portal. Administrators can search that code under Service Health in the Microsoft 365 Admin Center for live status and remediation notes.

Can users still sign in to Microsoft 365 during the MFA outage?

Most users with active sessions can, because the Entra Backup Authentication Service reissues tokens for existing sessions, which Microsoft says cover more than 90% of authentications. Users starting a new session that requires MFA, or guest users, are the ones most likely to be blocked.

Should administrators disable Conditional Access MFA requirements during the outage?

No, broad disabling is risky because it opens a security gap exactly when authentication is unstable. A safer approach is a narrow, temporary exclusion for the specific users who cannot complete registration, removed as soon as the service recovers.

How can new employees be onboarded while MySignIns is down?

Onboarding that depends on registering a first authentication method may need to pause until the portal returns, since new sessions are not covered by the backup service. Where it cannot wait, scope a time-boxed Conditional Access exclusion to those individual accounts rather than the whole tenant.

Where can administrators get real-time updates?

The two live sources are Service Health in the Microsoft 365 Admin Center, filtered to MO1329260, and the Microsoft 365 Status account on X. Microsoft also publishes a post-incident review through the Admin Center after the disruption is resolved.