What this check looks at
Checks that system-preferred MFA is on for all users, so people are asked for the strongest method they have registered rather than the one they chose.
When someone has registered several MFA methods, Entra ID has to decide which to ask for first. Without system-preferred MFA it uses the default method the person chose, which for many is still a text message because that was the first thing they set up. System-preferred MFA makes Entra ask for the strongest method the person has registered, such as a passkey or an Authenticator notification, while still letting them choose another from the sign-in screen.
The check fails when system-preferred MFA is disabled, or applies only to some groups rather than all users. It passes when it is enabled for all users, or left as Microsoft managed, which Microsoft has switched on for every tenant.
Text and voice codes are the weakest MFA methods: SIM-swap fraud, interception and real-time phishing all defeat them. A person who has Authenticator but is asked for a text by default is protected only as well as the text, and attackers phish for whichever method is offered.
Why it matters
Someone with a passkey and a phone number registered is otherwise often asked for a text message, the weakest of the two. System-preferred MFA always asks for the strongest, so the stronger methods people already have are actually used.
SIM-swap fraud is well known in the UK: an attacker persuades a mobile network to move the victim’s number to a new SIM and receives their texts. If that person’s Microsoft 365 sign-in defaults to a text code, an attacker who already has the password now has the second factor too, even though the person also had Authenticator on their phone.
System-preferred MFA costs nothing and changes nothing for people with a single method. For everyone else it quietly moves each sign-in to the strongest method they already have, which is also usually the quickest to approve.
The CIS Microsoft 365 Foundations Benchmark (5.2.3.6) asks for system-preferred MFA to be enabled, and NCSC guidance prefers app-based and phishing-resistant methods to text messages where they are available. The rule maps to NIST CSF 2.0 PR.AA-03.
How to fix it
Where: Entra admin centre → Protection → Authentication methods → Settings
Before you start
- Nothing to prepare. Users with only one method are unaffected.
Step by step
- Open the authentication method settings. In the Microsoft Entra admin centre, go to Entra ID > Authentication methods > Settings and find System-preferred multifactor authentication.
- Enable it for all users. Set State to Enabled (or Microsoft managed, which this check also accepts), set the include target to All users, and keep exclusions to groups with a documented reason, such as a test group. Select Save.
- Tell the service desk. Let the service desk know that people with several methods will now be asked for the strongest first, for example Authenticator rather than a text, and can still pick another method on the sign-in screen.
- Confirm. Reopen Settings and check System-preferred multifactor authentication shows Enabled (or Microsoft managed) for All users. A test user with both Authenticator and a phone number registered should be offered Authenticator first. Re-run the assessment to confirm.
What users will notice
People are asked for the strongest method they have registered (for example Authenticator rather than a text message). They can still choose another method from the sign-in screen.
How to confirm it worked
Entra admin centre, Authentication methods, Settings: System-preferred multifactor authentication is Enabled for All users.
Frameworks and controls
This check maps to controls in 16 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| Cyber Essentials Plus | Multi-factor authentication test on cloud services |
| 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 |
| 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 CDE |
| 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.8.5 Secure authentication |
| CIS M365 | 5.2.3.6 Ensure system-preferred multifactor authentication is enabled |
| 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
- System-preferred multifactor authentication (Microsoft Learn)