Monitoring: Microsoft Entra MFA & 'My Sign-Ins' Outage Impact

Solid query. I'm seeing a lot of noise in our logs right now that mimics denial-of-service on the registration endpoints. It's crucial to filter out the 500-series errors from the Microsoft backend so you don't trigger automated alert fatigue.

We're using the Microsoft Graph PowerShell module to check service health programmatically every 10 minutes to keep management updated:

Connect-MgGraph -Scopes "ServiceHealth.Read.All"
Get-MgServiceAnnouncement -Property Id, Service, Status | Where-Object { $_.Status -eq "incidentActive" }

This helps us avoid relying on the admin portal which is currently timing out.

From a SOC perspective, the scary part isn't just the setup outage; it's that users can't access 'My Sign-ins' to review active sessions. If an attacker compromises a session right now, the user can't revoke it via self-service.

We've forced a sign-out for our Tier 0 admin groups as a precautionary measure:

Get-MgGroupMember -GroupId "" | ForEach-Object { Revoke-MgUserSignInSession -UserId $_.Id }


It's disruptive, but given that users cannot audit their own sign-ins during this incident, we felt it was necessary.

Valid concern, Pat. Since users can't self-remediate risky sessions, we've dialed up alerting sensitivity for "Impossible Travel" and anonymous IP addresses. We need to intercept those threats before they establish persistence. If you're using Sentinel, here's a quick KQL query to surface high-risk sign-ins that need immediate manual review:

SigninLogs
| where RiskLevelDuringSignIn == "high" or RiskState == "atRisk"
| summarize Count=count() by UserPrincipalName, Location, IPAddress
| order by Count desc

Has anyone seen an increase in legacy auth attempts exploiting the gap?

Since new accounts are vulnerable without MFA, we should monitor for brute-force bursts targeting recently created onboarding users. Attackers often probe specifically for unprotected accounts during these outages. I'm using this KQL query to catch spikes in failed auth attempts against specific users during this window:

SigninLogs
| where CreatedDateTime > ago(1h)
| where ResultType in ("50126", "50053")
| summarize FailedAttempts = count() by UserPrincipalName, bin(CreatedDateTime, 10m)
| where FailedAttempts > 10

Solid advice. As a stopgap, I'm enforcing 'Compliant Device' requirements on high-value apps. Without MFA, device trust becomes our primary secondary layer.

To pinpoint impacted users trying to secure themselves, use this KQL to filter out the specific registration outage errors:

SigninLogs
| where Status.errorCode in (50089, 500121)
| summarize Count() by UserPrincipalName, AppDisplayName

Building on the brute-force angle, we're proactively identifying 'ghost' access—users logging in successfully with single-factor authentication during this window. We're piping that list to our SOAR playbook to temporarily disable accounts until MFA is restored.

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == "0"
| where AuthenticationRequirement == "singleFactorAuthentication"
| summarize LastLogin = arg_max(TimeGenerated, *) by UserPrincipalName

Great call on device compliance. To help pinpoint users stuck at the registration screen, run this KQL query. It identifies failed 'Register security info' attempts so you can manually follow up or enforce stricter Conditional Access policies for those specific high-risk accounts.

kusto

AuditLogs
| where OperationName == "User registered security info"
| where Result == "Failure"
| summarize Count = count() by UserId, InitiatedBy