What this check looks at
Checks for an enabled Conditional Access policy that requires MFA (or a phishing-resistant authentication strength) for all users across all cloud applications.
Registering a second factor does nothing on its own: Entra ID asks for it only when something requires it. In a tenant licensed for Microsoft Entra ID P1 (Microsoft 365 Business Premium, E3 or E5), that requirement comes from a Conditional Access policy; in a tenant without P1 it comes from security defaults. New tenants start with security defaults on, but many older tenants, and many where someone switched security defaults off to make an app work, have neither.
The check passes when security defaults are on, or when an enabled Conditional Access policy targets All users and All resources and grants access only with MFA or an authentication strength. It warns when every such policy carries more than five user and group exclusions, because exclusions are where these policies quietly erode. It fails when the only all-user MFA policy is in report-only mode, which enforces nothing, or when there is no such policy and security defaults are off.
Without enforcement, anyone who has the password signs straight in. Attackers get passwords from phishing pages, password spraying and breach lists, then sign in from their own laptop; Entra ID sees a correct password and lets them through. A policy that covers only a pilot group, only some apps, or excludes a growing list of people leaves the same door open for everyone outside it.
Why it matters
Registration without enforcement protects nobody: an attacker with a valid password simply does not use the second factor. Enforcement is what converts registration into prevented intrusions.
Most compromises of Microsoft 365 in small and medium UK organisations start with one phished password. The attacker reads the mailbox, works out who pays invoices, and either redirects a payment or uses the trusted mailbox to phish the firm’s own clients. A director’s account taken this way can be used to authorise bank transfers by email or to ask IT to reset other people’s passwords.
The cost is the lost payment, which is often never recovered, plus incident response, advice on whether the breach must be reported to the ICO under UK GDPR, and the time spent with alarmed customers. Requiring MFA everywhere stops nearly all of these attacks at the first step, at the price of an occasional prompt on a new device.
Cyber Essentials requires MFA on cloud services for all users wherever the service offers it. The CIS Microsoft 365 Foundations Benchmark (5.2.2.2) and the CISA SCuBA baseline (MS.AAD.3.2v2) both ask for a Conditional Access policy requiring MFA for all users, and NCSC guidance names MFA as one of the most effective controls an organisation can turn on. The rule maps to NIST CSF 2.0 PR.AA-05.
How to fix it
Where: Entra admin centre → Protection → Conditional Access
Before you start
- Confirm two emergency access (break-glass) accounts exist and exclude them from the policy, so a mistake cannot lock every administrator out.
- Make sure MFA registration is above 95% (see the registration coverage finding), or users will be prompted to register at an awkward moment.
- Create the policy in report-only mode first and review its results in Entra ID sign-in logs (Conditional Access tab) for at least a week.
Step by step
- Confirm the licence and the emergency access accounts. Check the tenant holds Microsoft Entra ID P1 (Microsoft 365 admin centre > Billing > Your products). If it does not, turn on security defaults instead (Microsoft Entra admin centre > Entra ID > Overview > Properties > Manage security defaults > Enabled) and stop here. If it does, confirm two emergency access accounts exist: cloud-only, on the .onmicrosoft.com domain, holding Global Administrator, with strong credentials (ideally FIDO2 keys) stored securely. Put them in a group used only for Conditional Access exclusions.
- Check registration first. Look at the MFA registration coverage finding, or Entra ID > Authentication methods > User registration details. If more than a few per cent of people are not MFA capable, get them registered first; otherwise the policy makes each of them register at an awkward moment, and an attacker who already has a password could register first.
- Create the policy in report-only mode. Go to Entra ID > Conditional Access > Policies and select New policy. Name it, for example, "CA02 – All users – Require MFA". Under Users, include All users; under Exclude, select the emergency access group and, in a synchronised tenant, Directory roles > Directory Synchronization Accounts. Under Target resources, include All resources with nothing excluded. Under Grant, choose Grant access and tick Require multifactor authentication (or Require authentication strength > Multifactor authentication). Set Enable policy to Report-only and select Create.
- Review the report-only results. After a few days of normal use, go to Entra ID > Monitoring & health > Sign-in logs, open a sample of sign-ins and look at the Report-only tab for this policy’s result. Look for accounts or apps that could not satisfy MFA: service accounts, scanners, old line-of-business apps. Fix them rather than exclude them, and keep exclusions to five or fewer users and groups in total; one group is best.
- Tell staff when it takes effect. Send a short note with the date and what to expect: an MFA prompt on new devices and when a session expires, answered with the Authenticator app or passkey they registered. Give them a contact for problems on the day.
- Switch the policy on. Open the policy, set Enable policy to On and select Save. If an older pilot policy requires MFA for only some users, it can be deleted once this one is on. Do not leave this policy in report-only: it enforces nothing in that state, and this check fails on it.
- Confirm it is enforcing. Sign in as a test user in a private browser window: you should be asked for MFA. In the sign-in logs, open that sign-in and check the Conditional Access tab shows the policy with result Success. Run What If (Conditional Access > Policies > What If) for an ordinary user and All resources to confirm the policy applies, then re-run the assessment.
What users will notice
Every sign-in asks for a second factor, usually only on new devices or after the session expires. Legacy apps that cannot do MFA stop working.
How to confirm it worked
In the sign-in logs, pick a few recent sign-ins and check the Conditional Access tab shows the policy as "Success" with MFA satisfied. The policy state must be On, not Report-only.
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 controlsIM-7 Restrict resource access based on conditions |
| 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 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.8.5 Secure authentication |
| CISA SCuBA | MS.AAD.3.2v2 MFA enforced for all users |
| CIS M365 | 5.2.2.2 Ensure multifactor authentication is enabled for all users |
| CIS Controls v8.1 | 6.3 Require MFA for externally-exposed applications (IG1)6.4 Require MFA for remote network access (IG1) |
| NIST CSF 2.0 | PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of dutiesPR.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
- Require MFA for all users (Microsoft Learn)