Microsoft 365 MFA: How to Check and Enforce It for Every User

Why 'MFA is on' is often not true

Tenants usually end up with a mix: security defaults switched off years ago, a Conditional Access policy that excludes a few accounts 'temporarily', a handful of users on the old per-user MFA setting, and shared or service accounts nobody wants to touch. Each exception is an account an attacker can take over with a password alone.

Microsoft now enforces MFA itself for sign-ins to its admin portals: the Azure portal, Entra admin center and Intune admin center since October 2024, the Microsoft 365 admin center since February 2025, and Azure command-line and API management since October 2025. That protects the admin portals. It does nothing for the mailbox of the person in finance who approves invoices.

How to check who is covered

Start with registration, then with enforcement. A user can only be challenged for MFA if they have registered a method.

1. Open the Entra admin center and go to Entra ID > Authentication methods > User registration details. The 'MFA capable' and 'Methods registered' columns show who has a usable second factor. Filter on users who are not MFA capable.
2. Go to Entra ID > Overview > Properties > Manage security defaults to see whether security defaults are on.
3. If security defaults are off, go to Entra ID > Conditional Access > Policies. You need a policy that requires multifactor authentication for all users and all resources, with its state set to On, not Report-only.
4. Open that policy and read the exclusions. Every excluded user or group needs a reason you can defend.

Do not use the per-user MFA page as your measure. A user protected by Conditional Access or security defaults shows as 'Disabled' there, and Microsoft documents that as the correct state. The page only tells you who is on the legacy per-user setting.

With Microsoft Graph PowerShell you can list every user without a registered method:

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Where-Object { -not $_.IsMfaRegistered } |
  Select-Object UserPrincipalName, MethodsRegistered

The older MSOnline and AzureAD PowerShell modules were retired in 2025. Scripts that still use Get-MsolUser no longer work.

How to enforce it

There are two supported routes. Pick one per tenant.

• Security defaults: free, on by default for tenants created since October 2019, and all or nothing. It requires MFA registration for everyone, challenges admins on every sign-in and blocks legacy authentication. Good for small tenants without Entra ID P1.
• Conditional Access: needs Entra ID P1, which is included in Microsoft 365 Business Premium and E3/E5. It lets you target users, apps and conditions, and is the right choice once you need any exception. Security defaults must be switched off before your own policies take over, so build the policies first.

With Conditional Access, use the template 'Require multifactor authentication for all users'. It starts in Report-only. Add your break-glass accounts as an exclusion (the template only excludes the admin who creates it), check the policy impact in the sign-in logs for a few days, then switch it to On.

Then raise the quality of the second factor. Number matching in Microsoft Authenticator has been enforced since May 2023, which stops most push-fatigue attacks. For admins, require a phishing-resistant method: passkeys (FIDO2 security keys or passkeys in Authenticator), Windows Hello for Business, or certificate-based authentication. Phishing kits that proxy the login page capture a one-time code just as easily as a password.

For MSPs: check every client the same way

The failure is rarely one tenant. It is the twentieth client, set up three years ago by someone who has since left, where security defaults were switched off for a scanner and never replaced. Run the same four checks on every tenant you manage, record the result, and repeat it: settings drift every time someone adds an exclusion.

Frequently asked