⚡ Why This Matters

In late July 2026, security researcher Ron Kagansky published a firsthand account of an account takeover that used nothing more exotic than a phone call. No malware, no phishing kit, no zero-day. The attacker needed exactly two things: the victim's phone number, and the fact that almost nobody changes their voicemail PIN.

Phone-based MFA was a reasonable default a decade ago. It no longer is. Voicemail-based OTP interception, SIM swapping, and SS7 network attacks have moved phone/SMS authentication from "acceptable" to "the method most likely to be the reason your next incident report starts with 'the attacker had valid MFA.'" Microsoft's own guidance has quietly shifted the same direction: phone authentication methods are explicitly called out as the weakest tier in the Authentication Methods policy, and Conditional Access authentication strengths treat them accordingly.

This guide gives you the full picture — how the attack actually works, why it works, and the exact Entra ID configuration (Authentication Methods policy, Conditional Access authentication strengths, and a Graph-based audit script) to close it without breaking sign-in for a few hundred users on a Tuesday morning.

🕵️ The Attack, Step by Step

Here's what Kagansky described, reconstructed as a timeline. Nothing here requires privileged access, insider knowledge, or custom tooling.

📞 Why Phone-Based MFA Fails Structurally

The voicemail path is one specific exploit. But it's a symptom of a broader problem: phone-based MFA (both voice call and SMS) authenticates possession of a phone number, not possession of a device or a cryptographic key. That distinction is the entire vulnerability.

Compare that to phishing-resistant methods, which authenticate a private key that never leaves a specific device:

This is exactly why Microsoft's Authentication Methods policy groups phone-based methods separately, and why Conditional Access authentication strengths let you require phishing-resistant MFA specifically — the platform already assumes phone auth is the weak tier. The gap is that most tenants inherited phone/SMS as an enabled legacy default and never revisited it.

🔍 Audit Your Exposure

Before disabling anything, find out how many users are actually relying on phone-based methods as their only strong authentication method — disabling it blind is how you generate a helpdesk queue, not a security improvement.

Microsoft Graph PowerShell — find every user still enrolled in phone auth

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","User.Read.All","AuditLog.Read.All"

$users = Get-MgUser -All -Property Id,UserPrincipalName,DisplayName,AccountEnabled |
    Where-Object { $_.AccountEnabled -eq $true }

$results = foreach ($u in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $u.Id -ErrorAction SilentlyContinue

    $phoneMethods = $methods | Where-Object {
        $_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.phoneAuthenticationMethod'
    }
    $strongMethods = $methods | Where-Object {
        $_.AdditionalProperties['@odata.type'] -in @(
            '#microsoft.graph.fido2AuthenticationMethod',
            '#microsoft.graph.windowsHelloForBusinessAuthenticationMethod',
            '#microsoft.graph.microsoftAuthenticatorAuthenticationMethod'
        )
    }

    if ($phoneMethods) {
        foreach ($pm in $phoneMethods) {
            [PSCustomObject]@{
                UserPrincipalName   = $u.UserPrincipalName
                DisplayName         = $u.DisplayName
                PhoneType           = $pm.AdditionalProperties['phoneType']        # mobile | alternateMobile | office
                PhoneNumber         = $pm.AdditionalProperties['phoneNumber']
                HasStrongMethodToo  = [bool]$strongMethods
                RiskLevel           = if ($strongMethods) { "Low — has a phishing-resistant fallback" }
                                      else { "HIGH — phone is the only strong factor" }
            }
        }
    }
}

$results | Sort-Object RiskLevel -Descending |
    Export-Csv -Path "PhoneAuthMethodAudit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

$highRisk = ($results | Where-Object { $_.RiskLevel -like "HIGH*" }).Count
Write-Host "Users with ONLY phone-based auth as their strong factor: $highRisk" -ForegroundColor Yellow

KQL — check sign-in logs for phone/voice MFA usage in the last 30 days

SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationDetails has "Phone" or AuthenticationDetails has "SMS" or AuthenticationDetails has "Voice call"
| extend AuthMethod = tostring(parse_json(AuthenticationDetails)[0].authenticationMethod)
| where AuthMethod in ("Phone call", "Text message", "SMS")
| summarize SignInCount = count(), LastUsed = max(TimeGenerated) by UserPrincipalName, AuthMethod
| order by SignInCount desc

Cross-reference this with the PowerShell audit above — users who show up in both are actively using phone auth today, not just enrolled in it as a stale fallback.

🔒 Lock It Down in Entra ID

Entra ID's Authentication Methods policy is where you control which methods can be used at all, tenant-wide or scoped to a group. This is the primary control — disable it here and the method simply can't be used, regardless of what's registered on an account.

Step 1 — Review current state

Step 2 — Scope phone/SMS to a shrinking exception group, not "All users"

# Create a group to hold temporary exceptions while you migrate users off phone auth
New-MgGroup -DisplayName "MFA-Phone-Auth-Exception" `
    -MailEnabled:$false -SecurityEnabled:$true -MailNickname "mfa-phone-exception"

# Set the Voice/SMS methods to target ONLY that group instead of All users
# (Authentication Methods policy is managed via Graph — no direct PowerShell cmdlet
#  for authenticationMethodConfigurations targets, so this uses Invoke-MgGraphRequest)
$body = @{
    "@odata.type"      = "#microsoft.graph.smsAuthenticationMethodConfiguration"
    state              = "enabled"
    includeTargets     = @(
        @{ targetType = "group"; id = "" }
    )
} | ConvertTo-Json -Depth 5

Invoke-MgGraphRequest -Method PATCH `
    -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Sms" `
    -Body $body

# Repeat with "#microsoft.graph.voiceAuthenticationMethodConfiguration" for the Voice endpoint

Step 3 — Once the exception group is empty, disable entirely

$disableBody = @{ state = "disabled" } | ConvertTo-Json

Invoke-MgGraphRequest -Method PATCH `
    -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Voice" `
    -Body $disableBody

Invoke-MgGraphRequest -Method PATCH `
    -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Sms" `
    -Body $disableBody

Step 4 — Enable and push phishing-resistant methods

🛡️ Conditional Access — Enforce, Don't Just Enable

Enabling strong methods isn't enough on its own — users will keep using whatever's fastest unless you require the stronger method for the sessions that matter. Authentication strengths in Conditional Access are the enforcement layer.

🗺️ Rollout Plan — Without Locking Anyone Out

👤 Individual-Level Fix (For Anyone Reading This Without an Entra Tenant)

Not everyone reading this manages an Entra tenant — some of you are just trying to protect your own phone number. Two actions, five minutes total:

If any of your accounts still offer "call me" or SMS as an MFA option, switch to an authenticator app (Microsoft Authenticator, or any TOTP app) wherever the service supports it. It's not phishing-resistant on its own, but it removes the voicemail path entirely.

✅ Pre-Rollout Checklist

• Ran the Graph PowerShell audit — have a list of users relying solely on phone/SMS auth
• Cross-checked sign-in logs (KQL) to confirm which accounts are actively using phone auth today
• Identified all privileged role holders (Global Admin, Privileged Role Admin, Security Admin) still on phone-only auth
• Created the temporary exception group for phased migration
• Enabled FIDO2 and enforced number matching on Microsoft Authenticator
• Notified affected users with a concrete, specific reason (this incident) — not a generic security email
• Built the Conditional Access "Phishing-resistant MFA" policy in Report-only mode first
• Reviewed Conditional Access insights workbook before enforcing
• Enforced phishing-resistant MFA for privileged roles first, then expanded to all users
• Disabled Voice and SMS authentication methods in the Authentication Methods policy once the exception group was empty
• Re-ran the audit script to confirm zero remaining phone-only accounts