Conditional Access and MFA

Conditional Access is a feature of Microsoft Entra ID that allows you to enforce access controls based on signals or conditions. It is the policy engine that decides whether to grant access, require additional verification (like MFA), or block access entirely. MFA (Multi-Factor Authentication) is a specific security method that requires two or more forms of verification from independent categories: something you know (password), something you have (phone, hardware token), or something you are (fingerprint, facial recognition).

Business Problem: Passwords are weak. They are often reused, guessed, or phished. Even strong passwords can be stolen. Conditional Access and MFA solve this by adding layers of verification and by making access decisions context-aware. For example, an employee logging in from a known device on the corporate network might only need a password, but the same employee logging in from a coffee shop in a foreign country would be prompted for MFA or blocked.

Conditional Access works like an if-then logic engine. When a user attempts to access a resource (e.g., Azure portal, Office 365, a custom app), Microsoft Entra ID evaluates the request against the Conditional Access policies. The evaluation flow is:

1. Signals Collection: Entra ID gathers signals such as user identity, device state (compliant or not), location (IP address, country), application being accessed, risk level from Identity Protection, and time of day. 2. Policy Evaluation: The collected signals are compared against the conditions defined in each policy. Conditions can include: user/group membership, location (trusted or untrusted), device platform, application, and sign-in risk. 3. Decision: Based on the policy, one of three actions occurs: - Grant Access: Allow access (possibly with session controls like app restrictions). - Require Additional Verification: Prompt for MFA, require a compliant device, or accept terms of use. - Block Access: Deny access entirely.

Example Policy: "If user is in the Finance group AND accessing the Payroll app from an untrusted location, then require MFA and block access if device is not compliant."

- User or group membership - Cloud apps or actions (e.g., Azure Management, Office 365) - Device state (compliant, domain-joined) - Location (IP ranges, countries) - Sign-in risk (low, medium, high) - Client apps (browser, mobile app, legacy auth) - Access Controls: The 'then' part. Grant controls include:

- Require MFA - Require device to be marked as compliant - Require Hybrid Azure AD joined device - Require approved client app - Require app protection policy - Require password change - Require terms of use - Session Controls: Fine-grained controls like app-enforced restrictions or Conditional Access App Control.

Conditional Access is available in different tiers: - Free/Basic (Azure AD Free): Limited. Only basic Conditional Access via security defaults (predefined policies that enforce MFA for all users, block legacy authentication, etc.). - Azure AD Premium P1: Full Conditional Access policies with conditions like location, device state, and application. This is the minimum for custom policies. - Azure AD Premium P2: Adds Identity Protection integration (risk-based Conditional Access) and Privileged Identity Management.

MFA itself is included with all tiers, but Conditional Access policies to enforce MFA require P1 or P2 (unless using security defaults).

On-premises, organizations used Active Directory with Group Policy and maybe a VPN with RADIUS for MFA. This was static: you either required MFA for all remote access or not. Conditional Access is dynamic and cloud-based. It evaluates risk in real time, integrates with thousands of SaaS apps, and can be updated centrally without touching servers. There is no on-premises equivalent that offers the same level of granularity and automation.

To manage Conditional Access in the Azure portal: navigate to Microsoft Entra ID > Security > Conditional Access. Here you can create new policies or view existing ones. Policies are JSON-based and can also be managed via Microsoft Graph API or PowerShell.

PowerShell example (using Microsoft Graph module):

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
    displayName = "Require MFA for Admins"
    state = "enabled"
    conditions = @{
        users = @{
            includeUsers = @("admin@contoso.com")
        }
        applications = @{
            includeApplications = @("All")
        }
    }
    grantControls = @{
        builtInControls = @("mfa")
        operator = "OR"
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

CLI example (using Azure CLI with Microsoft Graph extension): Not natively available; use Microsoft Graph API or PowerShell.

ARM/Bicep: Conditional Access policies are not directly deployable via ARM templates; use Microsoft Graph API or PowerShell/CLI with Graph.

Scenario 1: Remote Work Security A company with 500 employees transitions to remote work. They use Office 365 and a custom CRM. The security team wants to ensure that only managed devices can access corporate data. They create a Conditional Access policy: If the user is accessing Office 365 or the CRM, and the device is not marked as compliant (via Intune), then require MFA and block access if device is not compliant. They also require device enrollment in Intune. The result: employees must enroll their personal laptops in Intune and comply with security policies (e.g., encryption, antivirus). If a device is lost, the admin can wipe it remotely. Cost: Azure AD Premium P1 licenses for all users, plus Intune licenses. If set up incorrectly (e.g., excluding too many users or not enforcing device compliance), a stolen device could access data without MFA.

Scenario 2: High-Risk Sign-In Response A financial services firm uses Azure AD Premium P2 and Identity Protection. They configure a Conditional Access policy that triggers when sign-in risk is medium or high. The policy requires MFA and forces a password change. For example, if a user's credentials appear on the dark web, Identity Protection raises the user risk. On the next sign-in, Conditional Access evaluates the risk condition and requires MFA + password change. This prevents compromised accounts from being used. If the policy is too aggressive (e.g., low risk triggers MFA), users may be prompted frequently, causing frustration. Conversely, if risk thresholds are too high, compromised accounts may go undetected.

Scenario 3: Block Legacy Authentication A healthcare provider discovers that many data breaches originate from legacy protocols like POP3 and SMTP, which do not support MFA. They create a Conditional Access policy to block all legacy authentication. The policy condition: Client apps > Other clients (legacy). Access control: Block access. This immediately stops attackers using brute-force attacks on legacy protocols. However, if the policy is applied without testing, users with legacy email clients (e.g., Outlook 2010) will lose email access. The solution: communicate the change and upgrade clients. Common mistake: forgetting to exclude service accounts that use legacy protocols for system emails, causing outages.