Require MFA for all users by creating a Conditional Access policy that applies to the user population you want protected and enforces multi-factor authentication at sign-in. Exclude only tightly controlled break-glass accounts and test in report-only mode first. Check application and device compatibility, because some older sign-in flows may fail unless you update them or use modern authentication.
What a Conditional Access MFA policy actually enforces
In Microsoft Entra, “require MFA for all users” is not a single switch so much as a policy design choice: you define the user scope, the cloud apps or actions in scope, and the grant requirement that forces a second factor at sign-in. The control works best when you treat it as a baseline access rule, not as a one-time configuration task.
The policy should be built around the population you want to protect, then tested against the sign-in methods and apps that those users actually use. Microsoft documents the policy model and testing workflow in the Conditional Access Guide, which is especially useful when you need to decide where report-only mode, exclusions, and authentication-strength choices belong.
For most workforce deployments, the practical decision is whether to require MFA broadly for interactive sign-ins or to layer it more narrowly for higher-risk access paths. If you are using the policy to protect Microsoft 365, admin portals, or line-of-business apps, the same design principle applies: scope the rule to the identities that matter, then validate that the user journey still works after MFA is enforced.
How to structure the policy without creating avoidable lockouts
The safest pattern is to start with report-only mode, validate sign-in impact, and then move the policy to On once you have confirmed that the right users are being challenged and the right exceptions are preserved. That approach reduces the chance that an incomplete app inventory or an unexpected legacy protocol blocks a business-critical workflow.
Keep the exclusion list as small as possible and reserve it for tightly controlled break-glass accounts with strong monitoring. Historical breaches show why this matters: Microsoft Midnight Blizzard breach illustrates how a legacy test account without MFA can become an entry point, while the Colonial Pipeline ransomware attack shows the risk of leaving dormant access paths outside modern authentication controls.
You also need to check application compatibility before enforcing the policy everywhere. Some older sign-in flows, scripted logins, or non-modern clients may fail when MFA is turned on, so the operational task is not only to enable the policy but to verify which apps support modern authentication and which ones need remediation or replacement.
What to verify after rollout and when MFA is not enough by itself
After activation, verify that the policy is actually applied to all intended accounts, that privileged users are not bypassing the control through unmanaged exceptions, and that the sign-in logs show the expected MFA challenge behavior. The key question is whether the policy meaningfully changes authentication risk, not whether the toggle was switched on.
Enforcing MFA is powerful, but it does not eliminate session theft, token replay, or help-desk abuse. The CitrixBleed exploitation 2023 case is a reminder that attackers can sometimes bypass the sign-in moment entirely by stealing session material. That is why modern sign-in protection should be paired with session, token, and recovery hardening rather than treated as a standalone answer.
Risk and Threat Considerations
Weak MFA coverage creates a direct path from stolen credentials to account takeover, especially when users rely on legacy sign-in methods, push-based prompts, or shared recovery processes. The main exposure is not only password theft, but the attacker’s ability to turn one compromised login into sustained access across email, admin tools, and downstream cloud services.
Failure mechanism: An excluded or legacy-authenticated account is used as the bypass path, or an attacker defeats the second factor through prompt fatigue, token theft, or session replay after the first sign-in.
Impact: The attacker can authenticate as a legitimate user, access protected apps, move laterally into administrative workflows, and persist even when passwords are reset if session or token exposure is not addressed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines authenticator strength and MFA expectations for sign-in assurance. |
| Recommendation — Align sign-in requirements with NIST 800-63 authenticator assurance guidance and prefer phishing-resistant methods. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | MFA for all users is an organizational authentication control question. |
| IA-5 — Authenticator Management | Policy rollout depends on how authenticators are issued, protected, and managed over time. | |
| Recommendation — Require strong user authentication for all workforce sign-ins. Manage authenticator lifecycle and rotate or retire weak methods. | ||
| CIS Controls v8 | CIS-5 — Account Management | The question centers on enforcing access controls across user accounts and exceptions. |
| Recommendation — Audit account scope and remove unnecessary exceptions from MFA enforcement. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Conditional Access is an access-control implementation for user sign-ins. |
| Recommendation — Apply access-control policy consistently across the protected user population. | ||
Practitioner Guidance
What to prioritize: Protect the highest-value identities first, especially admins, help-desk operators, and users with access to sensitive apps. If you have not yet eliminated legacy authentication, treat that as part of the same rollout because MFA enforcement is only as strong as the weakest compatible sign-in path.
Decision rule: If an account must be excluded, make it a documented break-glass identity with separate monitoring, strong credential hygiene, and a clear owner. If an application cannot handle MFA cleanly, fix the app path rather than widening the exclusion set.
What to verify: Confirm the policy is enforced in production, not just created; confirm report-only results match the intended scope; and confirm that sign-in logs show the expected challenge rate for the user groups you intended to protect.
Practitioner takeaway: The right objective is not merely “turn on MFA,” but to make sure every meaningful sign-in path is covered without creating hidden exceptions that become the real attack surface.
Related resources from NHI Mgmt Group
- How do you require compliant devices with Conditional Access in Microsoft Entra ID?
- How do you require reauthentication with Microsoft Entra Conditional Access?
- How do you apply Conditional Access policies to AI agents in Microsoft Entra?
- How do you secure AI agent identities with Microsoft Entra Conditional Access?