There is no convenient way to find out if Multi-Factor Authentication is enabled for a particular user and what MFA methods are configured in the Microsoft 365 Admin Centre web interface.
In this article, we’ll show how to retrieve registered authentication methods for Microsoft 365 users and use them to understand available authentication methods and potential MFA capability (not enforcement).
Keep in mind that registered authentication methods do not necessarily mean that MFA is enforced for a user. Actual MFA enforcement typically depends on Conditional Access policies, Security Defaults, and Authentication Strengths.
Some older Microsoft 365 tenants may still contain users configured with legacy Per-User MFA settings. While these settings can still be encountered in existing environments, we recommend using Conditional Access-based MFA instead.
Introduction
Previously, you could use the Get-MsolUser cmdlet from the MsOnline module or the Get-AzureADUser cmdlet from the AzureAD module to get the MFA status of Microsoft 365 users. However, after 30 June 2023, legacy Azure AD and MSOL modules (which use the Azure AD API) have been deprecated. So, now you must use the Microsoft Graph PowerShell module to retrieve user authentication methods in your Azure tenant.
Installing PowerShell module Microsoft Graph
Install the PowerShell module Microsoft Graph for all users on your computer:
Install-Module Microsoft.Graph -Scope AllUsers -force
You can check if your computer has Microsoft Graph installed:
Get-InstalledModule Microsoft.Graph

Connect your tenant
Then connect to your tenant using the Microsoft Graph module:
Connect-MgGraph -Scopes "User.Read.All,UserAuthenticationMethod.Read.All"
Authenticate and grant the Microsoft Graph command line tools permissions to read all Azure user properties and authentication methods.

If you’ve successfully authenticated to Azure via PowerShell, you should see the message “Welcome to Microsoft Graph!
How to Get Registered Authentication Methods for a User
Run the following command to retrieve registered authentication methods for a user:
Get-MGUserAuthenticationMethod -userid kirill@theitbros.onmicrosoft.com | fl

Only Password Authentication is registered for the user in this example. This means that that no additional authentication methods have been configured. However, note that registered methods alone do not determine whether MFA is enforced (MFA enforcement depends on tenant security policies such as Conditional Access, Security Defaults, Authentication Strengths, or legacy Per-User MFA settings).
If the user has additional authentication methods configured, the Get-MgUserAuthenticationMethod cmdlet lists them.
For example, my account is configured to authenticate using the Microsoft Authenticator app on a mobile device:
(#microsoft.graph.microsoftAuthenticatorAuthenticationMethod)

Other strong MFA authentication methods including biometrics, authenticator applications, hardware security keys, etc. can be configured for the user.
Hint. An error occurs if you have not granted access to UserAuthenticationMethod.Read scope:
Get-MgUserAuthenticationMethod_List1: Request Authorization failed
How to Identify Authentication Methods Registered in Microsoft Entra ID
Note. The following script does not determine whether MFA is enforced for a user. Instead, it analyzes the authentication methods registered in Microsoft Entra ID and reports whether the user has configured MFA-capable authentication methods (such as Microsoft Authenticator, FIDO2 security keys, phone authentication, Windows Hello for Business, or Temporary Access Pass).
If multiple MFA methods are configured for a user, the command output can be difficult to understand which methods are enabled.
So you can use this PowerShell script to identify authentication methods registered in Microsoft Entra ID for a user. Our script checks if the user has registered MFA-capable authentication methods (such as Microsoft Authenticator, FIDO2 security keys, phone authentication, Windows Hello for Business, Software OATH, or Temporary Access Pass).
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All","UserAuthenticationMethod.Read.All"
# Get all users in tenant
$users = Get-MgUser -All -Property Id,UserPrincipalName
$result = foreach ($user in $users) {
try {
$methods = Get-MgUserAuthenticationMethod -UserId $user.Id
$report = [PSCustomObject]@{
UserPrincipalName = $user.UserPrincipalName
HasMfaCapableMethods = $false
RegisteredMethodsCount = 0
PasswordAuthentication = $false
MicrosoftAuthenticator = $false
Fido2SecurityKey = $false
PhoneAuthentication = $false
SoftwareOath = $false
TemporaryAccessPass = $false
WindowsHelloForBusiness = $false
HardwareOath = $false
}
foreach ($method in $methods) {
switch ($method.AdditionalProperties['@odata.type']) {
"#microsoft.graph.passwordAuthenticationMethod" {
$report.PasswordAuthentication = $true
}
"#microsoft.graph.microsoftAuthenticatorAuthenticationMethod" {
$report.MicrosoftAuthenticator = $true
$report.HasMfaCapableMethods = $true
}
"#microsoft.graph.fido2AuthenticationMethod" {
$report.Fido2SecurityKey = $true
$report.HasMfaCapableMethods = $true
}
"#microsoft.graph.hardwareOathAuthenticationMethod" {
$report.HardwareOath = $true
$report.HasMfaCapableMethods = $true
}
"#microsoft.graph.phoneAuthenticationMethod" {
$report.PhoneAuthentication = $true
$report.HasMfaCapableMethods = $true
}
"#microsoft.graph.softwareOathAuthenticationMethod" {
$report.SoftwareOath = $true
$report.HasMfaCapableMethods = $true
}
"#microsoft.graph.temporaryAccessPassAuthenticationMethod" {
$report.TemporaryAccessPass = $true
$report.HasMfaCapableMethods = $true
}
"#microsoft.graph.windowsHelloForBusinessAuthenticationMethod" {
$report.WindowsHelloForBusiness = $true
$report.HasMfaCapableMethods = $true
}
}
}
$report.RegisteredMethodsCount = $methods.Count
# Note:
# PasswordAuthenticationMethod is always present.
# Therefore, RegisteredMethodsCount = 1 does NOT indicate MFA absence alone
# and must not be interpreted as MFA status.
$report
}
catch {
[PSCustomObject]@{
UserPrincipalName = $user.UserPrincipalName
Error = $_.Exception.Message
}
}
}
# Export report
$result | Export-Csv ".\MFA-Authentication-Report.csv" -NoTypeInformation -Encoding UTF8
# Optional view
$result | Sort-Object HasMfaCapableMethods -Descending | Format-Table -AutoSize
The script will return HasMfaCapableMethods = False in case the user is configured to use password authentication only.

If one or more non-password authentication methods are registered in addition to Password Authentication, the script reports HasMfaCapableMethods = True.
Keep in mind that this result reflects user registration status only. It does not confirm that MFA is currently enforced during sign-in. In order to check actual MFA enforcement, you need to review Conditional Access policies, Security Defaults config, Authentication Strength requirements, or legacy Per-User MFA settings in your Microsoft Entra tenant.
How to Check Legacy Per-User MFA State (Graph API Beta)
In addition to Conditional Access and Security Defaults, Microsoft Entra ID also supports legacy Per-User MFA config. Although this method is deprecated, you may still use it in some tenants.
In order to retrieve the Per-User MFA state for a user, you can use Microsoft Graph beta API:
$UserId = "user@domain.com"
Invoke-MgGraphRequest -Method GET -Uri "/beta/users/$UserId/authentication/requirements"
Note that you should not use legacy Per-user MFA should for modern MFA assessment. If required for audit purposes only, use it as historical data, not as a control signal.
The response includes the field:
perUserMfaState
Here are the possible values:
- enabled
- disabled
- enforced
This allows you to determine whether legacy Per-User MFA is still applied to the user.
Note. This endpoint is part of Microsoft Graph beta and may change or be removed in future releases. You should not use it as the only source of truth for MFA enforcement decisions.
Checking if MFA Is Enforced
The following command checks if Security Defaults are enabled in the tenant (however, you can also configure MFA enforcement through Conditional Access/other policies):
Note. Security Defaults and Conditional Access are mutually exclusive. In case Conditional Access is enabled in a tenant, Security Defaults are automatically disabled and no longer control MFA enforcement. In most enterprise environments, you should use Conditional Access instead of Security Defaults.
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy
To determine whether MFA is actually required during sign-in, you should review:
- Security Defaults
- Conditional Access policies
- Authentication Strength policies
Note that in older tenants, you may also encounter legacy Per-User MFA configs that were created before Microsoft Entra Conditional Access became the preferred MFA enforcement method.
Also, keep in mind that a user can have Microsoft Authenticator, FIDO2 keys, or other methods registered without being required to use MFA during authentication.

Nice script, but the fact that we have to calculate and “guess” whether a user is actually required to use MFA is a typical oversight on Microsoft’s part. I have people who have their MFA status as “Disabled” in the O365 MFA settings, but come back as MFA Enabled using this script. And the O365 GUI unfortunately doesn’t allow you to filter by “Disabled”, only Enabled and Enforced. Typical half-baked half-ass Microsoft.
GUI is showing that MFA is disabled, but CLI and this script is showing that MFA is enabled. The user cannot user email using SMTP script , as user cannot login. MFA needs to be disabled.
The problem is that you can have all the auth methods in the world configured, but if you don’t enable / enforce it, it won’t require the user to use MFA and this script is assuming he does have it enabled by default.