Multi-Factor Authentication and Conditional Access are two of the most important security features in Microsoft Entra ID. They are also commonly misunderstood, and the distinction between them matters more than most organizations realize. If you are responsible for securing Microsoft 365, Azure, or Entra ID, understanding what each technology does and how they relate to each other is foundational to building a secure environment.
This post and video breaks down both technologies from the ground up, covers the MFA options available in Entra ID, explains why some are stronger than others, and shows how Conditional Access brings it all together with signal-based access control. No prior experience with either technology is required.
What Is Multi-Factor Authentication?
At its core, Multi-Factor Authentication adds an additional requirement during sign-in. Instead of relying on just a username and password, users must provide more than one form of verification before access is granted.
That verification can come from three categories of factors. Something you know, such as a password or PIN. Something you have, such as a hardware token or mobile device. Or something you are, such as a fingerprint or facial recognition. MFA simply requires a combination of these factors during the sign-in process.
The reason MFA matters so much is straightforward. Passwords are frequently compromised through phishing, data breaches, and credential stuffing attacks. Adding a second factor means that even if an attacker has a user’s password, they still cannot complete the sign-in without the second factor. Microsoft reports that MFA blocks over 99% of account compromise attacks.
How MFA Works in Microsoft Entra ID
Every user account in Entra ID contains a collection of attributes. These include details such as the user’s name, User Principal Name, Object ID, group memberships, and many other properties.
One of those properties is the user’s registered authentication methods. This is an important concept: MFA methods are part of the user account. The Entra ID user object stores the authentication methods that the user has registered and can use for verification. You can see this by opening a user account in Entra ID and selecting Authentication Methods, which shows every MFA method currently registered on that account.
The Authentication Methods Policy
As an administrator, you want control over which authentication methods users can register and use. That is exactly what the Authentication Methods policy in Entra ID is designed for. From here, you can enable or disable various authentication methods across the tenant, including Microsoft Authenticator, Passkeys, OATH tokens, Windows Hello for Business, SMS, voice calls, and more. You can also target specific groups, which means you can define different available methods for different sets of users.
One important note: Microsoft has announced the retirement of SMS and voice-based authentication. If your organization still relies on SMS or phone calls for MFA, now is the time to plan a transition to stronger methods.
Not All MFA Is Equal – Authentication Strengths
Enabling MFA is a significant step forward, but it is worth understanding that not all MFA methods provide the same level of protection.
SMS-based authentication is vulnerable to SIM swapping, where an attacker convinces a mobile carrier to transfer a phone number to a SIM card they control. Once they have the number, they receive the verification codes. OATH token codes and push notifications can be captured and replayed by attackers sitting between the user and a fake login page. Push notifications without additional context are also vulnerable to MFA fatigue attacks, where an attacker repeatedly sends approval requests hoping the user taps Approve just to make them stop.
At the top of the security stack are phishing-resistant methods: FIDO2 passkeys and Windows Hello for Business. These methods work fundamentally differently from all others. The authentication is cryptographically bound to the exact domain the user is signing into. There is no code to intercept, no push notification to approve, and no way for an attacker to redirect the authentication to a fake site. If the domain does not match, the authentication simply does not work. For high-value accounts like Global Administrators, phishing-resistant MFA should be the target.
This is where Authentication Strengths come in. After you have enabled authentication methods in Entra ID, Authentication Strengths allow you to define exactly which methods satisfy a particular authentication requirement. Microsoft provides three built-in Authentication Strengths: Multifactor Authentication, which accepts any MFA method; Passwordless MFA, which requires Microsoft Authenticator passwordless, FIDO2 passkeys, or Windows Hello for Business; and Phishing-resistant MFA, which is limited to FIDO2 passkeys, Windows Hello for Business, and certificate-based authentication. Custom Authentication Strengths can also be created if the built-in options do not meet your needs.
MFA Methods – Weakest to Strongest
SMS and Voice – Vulnerable to SIM swapping and real-time phishing. Being retired by Microsoft.
OATH Software Tokens – Stronger than SMS but still vulnerable to real-time phishing.
Microsoft Authenticator with Number Matching – Significantly stronger. Breaks MFA fatigue attacks.
Passwordless Authenticator – No password required. Stronger but not fully phishing-resistant.
FIDO2 Passkeys and Windows Hello for Business – Phishing-resistant. The gold standard for high-value accounts.
Why Per-User MFA Should Be Avoided
If you open users in Entra ID, you will find the option for Per-User MFA, which allows administrators to enable, disable, or enforce MFA on an individual user basis. The recommendation here is simple: do not use it.
Per-User MFA does not allow you to distinguish between stronger and weaker authentication methods. An SMS code is treated exactly the same as a phishing-resistant passkey. Management options are limited, compatibility can be problematic in certain SSO scenarios, and it conflicts with Conditional Access policies. Per-User MFA is a legacy approach and should not be part of a modern Entra ID security strategy.
What Is Conditional Access?
If MFA defines how users authenticate, Conditional Access is the decision-making engine that determines when and how that authentication is enforced.
Conditional Access evaluates signals during the sign-in process and applies a set of if-then rules to determine whether access should be granted, blocked, or granted only under specific conditions. Those signals include who the user is, what application they are accessing, where they are signing in from, what device they are using, and what level of sign-in risk has been detected.
Importantly, Conditional Access goes well beyond MFA enforcement. It is the foundation of a Zero Trust security model for Microsoft cloud identity. Organizations use it to make intelligent access decisions based on context rather than applying a single blanket policy to everyone.
Real-World Conditional Access Scenarios
The power of Conditional Access becomes clear when you look at what it enables in practice. Rather than requiring MFA for every sign-in regardless of context, you can create policies that match the actual risk of each access scenario.
A user signing in from a trusted corporate network during normal business hours presents a very different risk profile than someone signing in from an unfamiliar location at 2am. Conditional Access lets you treat those scenarios differently. You might allow the first user to access resources without an additional challenge, while requiring MFA from the second. You might require phishing-resistant authentication for any account with administrative privileges, regardless of location. Or you might require a compliant, managed device before granting access to sensitive Microsoft 365 resources.
This is where the relationship between MFA and Conditional Access becomes clear. MFA methods and Authentication Strengths define the authentication options available to users and how strong those options are. Conditional Access determines when those methods are required and which strength is appropriate for a given scenario. If you look at the Grant controls in a Conditional Access policy, you can choose to require MFA or require a specific Authentication Strength. That is how you enforce exactly the level of authentication needed based on the context of each sign-in.
Security Defaults – A Middle Ground
Some organizations are not yet ready to implement Conditional Access, whether because of licensing requirements or because of the complexity involved in building and testing policies. In those situations, a better alternative to Per-User MFA is Entra ID Security Defaults.
Security Defaults are a set of baseline security protections that can be enabled across an entire tenant with a single toggle. They enforce MFA registration for all users, require MFA for administrators on every sign-in, and block legacy authentication protocols. Security Defaults are free, require no configuration, and provide meaningful protection for organizations that are just getting started.
The trade-off is flexibility. Security Defaults offer no customization. You cannot exclude users, target specific apps, or set different requirements based on location or device. When your organization needs that level of control, Conditional Access is the right tool. But for organizations that have not yet taken any steps toward MFA enforcement, Security Defaults are a far better starting point than Per-User MFA.
How MFA and Conditional Access Work Together
The simplest way to understand the relationship between these two technologies is this: MFA methods are attributes of the user. Conditional Access is the policy engine that decides when those methods are required.
A user registers their authentication methods once, and those methods are stored as part of their Entra ID user object. Conditional Access policies then evaluate every sign-in against the rules you have defined and determine what is required for that specific access request. The result is a dynamic, context-aware security model that can apply the right level of authentication for every scenario without burdening users with unnecessary friction.
Together, MFA and Conditional Access form the foundation of Zero Trust identity security in Microsoft Entra ID. Zero Trust is built on the principle of never trust, always verify. Every sign-in is evaluated. Every access decision is made based on real signals rather than assumed trust. MFA provides the verification. Conditional Access provides the intelligence to apply that verification where it matters most.
Take Action Today
If your organization has not yet implemented MFA, the first step is enabling it. Security Defaults are the fastest path for organizations starting from scratch. For organizations that need more control, Conditional Access with a policy requiring MFA for all users is the right foundation to build on.
If MFA is already in place, the next question is whether the right methods are being enforced. Reviewing the Authentication Methods policy, understanding Authentication Strengths, and ensuring that privileged accounts are protected with phishing-resistant MFA are the logical next steps. The Entra ID portal gives you everything you need to evaluate your current configuration and make improvements without disrupting users.
For a deeper look at each of these topics with full portal demonstrations, the Securing Entra ID with MFA and Conditional Access video series covers everything from the fundamentals through advanced Authentication Strengths and real-world Conditional Access policy scenarios.
Links:
A Beginner’s Guide to the AZ-900
https://www.udemy.com/course/beginners-guide-az-900/?referralCode=C74C266B74E837F86969
Zero to Hero with Azure Virtual Desktop
https://www.udemy.com/course/zero-to-hero-with-windows-virtual-desktop/?referralCode=B2FE49E6FCEE7A7EA8D4
Hybrid Identity with Windows AD and Azure AD
https://www.udemy.com/course/hybrid-identity-and-azure-active-directory/?referralCode=7F62C4C6FD05C73ACCC3
Windows 365 Enterprise and Intune Management
https://www.udemy.com/course/windows-365-enterprise-and-intune-management/?referralCode=4A1ED105341D0AA20D2E
Playlist: Securing Entra ID with MFA and Conditional Access
https://www.youtube.com/playlist?list=PLFeafTOIudJc
Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
Security defaults in Microsoft Entra ID
https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults
