Multi-Factor Authentication and Conditional Access

Stolen credentials are the leading cause of cloud security breaches. A password alone can be phished, guessed through brute force, or leaked from a third-party breach. Multi-Factor Authentication (MFA) requires a second verification factor that an attacker is unlikely to possess even after obtaining a password — dramatically reducing the risk of unauthorised access to your Azure environment.

Entra ID supports multiple MFA verification factors. The most secure and recommended option is the Microsoft Authenticator app, which provides number matching and push notifications. Other options include a FIDO2 security key (hardware token), a software OATH token, SMS text message, or a voice call. SMS and voice are considered lower security and should be used only as fallbacks.

MFA in Entra ID can be enforced through three mechanisms. Security defaults is the free, one-click option that enforces MFA for all users but without customisation. Per-user MFA (legacy) enables MFA on specific user accounts. The recommended modern approach is Conditional Access policies (Entra ID P1/P2), which enforce MFA only when specified risk conditions are met, reducing user friction for low-risk sign-ins.

Conditional Access (Entra ID P1) is an if-then policy engine: if a user (or group) tries to access a resource under certain conditions, then grant access, block access, or require additional controls like MFA or a compliant device. Conditions can include user identity, device compliance, IP location, application being accessed, and Entra ID Identity Protection risk score.

A Conditional Access policy has two parts: Assignments (who and what the policy applies to) and Access Controls (what happens when the policy triggers). Assignments define the Users/groups, the Cloud apps being accessed, and the Conditions (location, device platform, sign-in risk). Access Controls define whether to Grant (optionally requiring MFA, compliant device, or approved app) or Block access entirely.

Conditional Access named locations let you define trusted IP ranges (such as your corporate office network) or countries. A common policy pattern is: require MFA when a user signs in from outside a trusted named location, but allow pass-through when signing in from a known office IP. This reduces friction for on-site employees while strengthening security for remote or travelling users.

Conditional Access can require that the accessing device is compliant (meets Intune device compliance policies) or is a hybrid Azure AD joined corporate device. This ensures that even if credentials are valid, sign-ins from personal or unmanaged devices are blocked or required to satisfy additional controls. Device-based controls are a key pillar of a Zero Trust security model.

Entra ID Identity Protection (P2) uses machine learning to evaluate every sign-in and assign a risk score: low, medium, or high. Risk factors include impossible travel (signing in from two countries within minutes), anonymous IP, leaked credentials, and password spray detection. Conditional Access policies can trigger on risk level — for example, requiring MFA for medium risk and blocking access for high risk automatically.

Before enforcing a Conditional Access policy, you can set it to Report-Only mode. In this mode the policy evaluates against all sign-ins and records what would have happened (granted, blocked, or MFA required), but does not actually enforce the controls. This lets you validate the policy's impact on your users before enabling it, preventing unexpected lockouts from poorly scoped conditions.

The What If tool in the Conditional Access blade lets you simulate a sign-in scenario — specifying a user, application, IP address, device platform, and risk level — and see which policies would apply and what the combined outcome would be. This is invaluable for troubleshooting access issues and validating that your policy set produces the expected outcome for given users and conditions.

Every organisation should maintain at least two break-glass emergency access accounts that are excluded from all Conditional Access policies, including MFA requirements. These accounts are used only if the MFA infrastructure fails or all administrators are locked out. Break-glass credentials should be stored in a physical safe, use long random passwords, have no MFA registered, and be audited heavily for any usage.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: MFA requires a second factor beyond a password, dramatically reducing credential theft risk, Conditional Access policies apply grant or block controls based on user, app, location, and risk conditions, and Identity Protection uses ML-based risk scoring to trigger automatic access controls. Next up we explore Single Sign-On and External Identities in Entra ID.