What this check looks at
Measures how many enabled member accounts are MFA capable: registered for a multi-factor method that the authentication methods policy allows.
Microsoft Entra ID records, for every account, which authentication methods it has registered: Microsoft Authenticator, a passkey or FIDO2 security key, Windows Hello for Business, a phone number for text or voice codes, and so on. An account counts as MFA capable only when it has registered a method that the authentication methods policy still allows: a phone number registered years ago stops counting once text message and voice call are turned off. Nothing makes people register unless security defaults or a policy asks them to, so accounts created through a joiner process often sit with a password and nothing else.
The check takes every enabled member account (guests, disabled accounts and accounts licensed only as students are left out) and looks each one up in the registration details report. It passes when every one of them is MFA capable. It warns when coverage is at or above the target, 97% unless the workspace has set its own, and fails below the target; below 60% the finding is raised as critical. The evidence lists up to 25 accounts with no usable method, and counts separately those that registered only methods that have since been turned off.
An account with no second factor is protected by its password alone, and passwords are phished, reused from breached websites and guessed by password-spray attacks that try a few common passwords against every account. Worse, when MFA is later enforced, an unregistered account is asked to register at its next sign-in, so an attacker who already holds the password can register their own phone and keep the account. Unregistered accounts are both the easiest way in and a way to stay in.
Why it matters
Accounts without a second factor are the single most common entry point for business email compromise. Microsoft reports that MFA blocks the overwhelming majority of credential-based attacks; every unregistered account is an unprotected door.
A typical case in a small UK firm: the finance assistant’s account never registered MFA, and her password is the same one she used on a shopping site that was breached. A password-spray attack finds it. The attacker reads weeks of correspondence with suppliers, adds an inbox rule to hide replies, and sends a convincing request to change a supplier’s bank details. The next payment run sends tens of thousands of pounds to the attacker, and banks rarely recover money once it has been moved on.
Beyond the lost payment, the business pays for incident response and a forensic review of what was read, and must decide within 72 hours whether to report a personal data breach to the ICO under UK GDPR. Customers and suppliers who received mail from the compromised account have to be warned, and the cyber insurer will ask whether MFA was in place; most proposal forms now ask exactly that.
Cyber Essentials requires multi-factor authentication on cloud services for every user and administrator wherever the service offers it, so unregistered accounts can fail an assessment. The CIS Microsoft 365 Foundations Benchmark (5.2.3.4) asks for every user to be MFA capable, NCSC guidance treats MFA as one of the most effective defences for online services, and the rule maps to NIST CSF 2.0 PR.AA-03 and the Essential Eight multi-factor authentication strategy.
How to fix it
Where: Entra admin centre → Protection → Authentication methods
Before you start
- Export the unregistered accounts from the evidence and check which are real people, shared mailboxes or service accounts.
- Decide which methods you will allow: Microsoft Authenticator for most staff, FIDO2 keys or Temporary Access Passes for people without a work phone.
- Tell users what is changing and when, with a contact for problems.
Step by step
- Export the accounts with no usable method. In the Microsoft Entra admin centre, go to Entra ID > Authentication methods > User registration details. Filter Multifactor authentication capable to show only the accounts that are not capable, and User type to Member, then select Download. The list should match the accounts in this finding’s evidence; the report can lag behind registrations by a few hours.
- Sort out accounts that are not people. Go through the list with the client. Shared mailboxes, room and equipment accounts should never be signed in to: block sign-in for them (Microsoft 365 admin centre > Users > Active users > select the account > Block sign-in), which takes them out of this count. A service account that cannot do MFA should be replaced by an app registration or managed identity, or left out of MFA by one narrow, documented Conditional Access exclusion. What remains is people who need to register.
- Check the methods people will register are allowed. Go to Entra ID > Authentication methods > Policies. Make sure Microsoft Authenticator is enabled for All users, and that Passkey (FIDO2) and Temporary Access Pass are enabled at least for the people who will need them. A method turned off here does not make anyone MFA capable, however many people registered it.
- Turn on the registration campaign. Go to Entra ID > Authentication methods > Registration campaign and select Edit. Set State to Enabled, include All users, keep Microsoft Authenticator as the method, set Days allowed to snooze to a few days and turn on Limited number of snoozes. The campaign prompts people at sign-in, after their usual MFA, to set up Authenticator; it moves those still on text or voice codes to a method the policy will keep allowing.
- Ask the remaining people to register now. Email everyone on the list a short guide and a deadline: sign in at https://aka.ms/mysecurityinfo, choose Add sign-in method and set up Microsoft Authenticator or a passkey. It takes a few minutes and needs no admin rights. Offer a short call for anyone who gets stuck, and chase non-responders through their manager.
- Issue Temporary Access Passes where needed. For people with no smartphone, or who cannot complete registration, go to Entra ID > Users, select the person, open Authentication methods > Add authentication method > Temporary Access Pass, and create a one-time pass valid for a few hours. They use it to sign in and register a FIDO2 security key or Windows Hello. Give the pass by phone after confirming who you are speaking to, never by email to the account itself.
- Enforce MFA once nearly everyone is registered. When coverage passes 95%, make sure a Conditional Access policy requires MFA for all users (the MFA enforcement finding describes it step by step). Anyone still unregistered is then made to register at their next sign-in, so chase the last few personally first rather than leaving it to the policy.
- Confirm coverage. Return to User registration details and filter on accounts that are not MFA capable: only accounts you have deliberately left should remain. Re-run the assessment; the finding passes when every enabled member account is MFA capable and warns between the target and 100%.
What users will notice
Users without a method are prompted to register at their next sign-in. It takes a few minutes; the registration campaign can be snoozed a limited number of times.
How to confirm it worked
In Entra ID, Protection, Authentication methods, User registration details: filter on "Multifactor authentication capable = No". The list should be empty apart from accounts you have deliberately excluded.
Frameworks and controls
This check maps to controls in 18 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| Cyber Essentials | User access control |
| Cyber Essentials Plus | Multi-factor authentication test on cloud servicesUser access control |
| NCSC CAF | B2.a Identity verification, authentication and authorisation |
| DSPT | Standard 4: Managing data access |
| DORA | Art. 9(4)(d) Strong authentication mechanisms |
| NIS2 | Art. 21(2)(j) Multi-factor authentication and secured communications |
| Microsoft Cloud Security Benchmark | IM-6 Use strong authentication controls |
| Zero Trust | Identities |
| Secure Score | Ensure all users can complete multifactor authentication |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| PCI DSS 4.0.1 | 8.4.2 MFA for all access into the CDE8.4.3 MFA for all remote network access |
| NIST SP 800-171 | 3.5.3 Use multi-factor authentication |
| CMMC Level 2 | IA.L2-3.5.3 Multifactor Authentication |
| ISO 27001:2022 | A.5.17 Authentication informationA.8.5 Secure authentication |
| CIS M365 | 5.2.3.4 Ensure all member users are 'MFA capable' |
| CIS Controls v8.1 | 6.3 Require MFA for externally-exposed applications (IG1) |
| NIST CSF 2.0 | PR.AA-03: Users, services, and hardware are authenticated |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Plan a multifactor authentication deployment (Microsoft Learn)
- Authentication methods registration campaign (Microsoft Learn)