Skip to main content
Implementing Azure AD Conditional Access lets you create policies that automatically decide who can access cloud applications and under what conditions. This guide explains the core concepts, shows a portal walkthrough to create a sample policy, and describes tools for testing and troubleshooting.

​
What is Conditional Access?

Azure AD Conditional Access evaluates signals about a sign-in attempt and enforces policies that determine the result. It’s a central part of identity-based security and complements MFA and Azure AD Identity Protection. Overview: signals → policies → apps/data
  • Signals (user, device, location, application, sign-in risk, etc.) are evaluated at every sign-in.
  • When signals meet policy conditions, Conditional Access evaluates and enforces an outcome.
  • Outcomes include allowing access, requiring multi-factor authentication (MFA) or other controls, or blocking access entirely.
Every access attempt results in one of these outcomes:
  • Allow access (no additional challenge).
  • Require MFA (or another configured control) before granting access.
  • Block access (deny access to the requested app/resource).

​
How Conditional Access works

Signals include user and group membership, device state, application being accessed, IP/location, client application type, and risk levels determined by Identity Protection (user risk and sign-in risk). Policies are evaluated in real time and enforce one of the outcomes above. Example use case: allow access only from a trusted corporate network. Even if a user has valid credentials, Conditional Access can prevent access unless the sign-in originates from the approved network.

​
Key features

FeaturePurposeExamples
ConditionsDefine when a policy appliesUsers/groups, device state (compliant), location/IP ranges, client app type, platform, sign-in or user risk
Access controlsDefine what happens when conditions are metAllow, Block, Require MFA, Require device compliance, Require approved client app, Require hybrid Azure AD join, Require authentication strength
Password reset or forcing a password change is generally handled by Azure AD Identity Protection risk remediation policies rather than as a Conditional Access grant control.
A slide titled "Key Features" with two panels labeled "Conditions" and "Access control," each containing a short explanatory blurb. Below the panels are colored circular icons: an orange clipboard-and-pen icon for Conditions and a blue lock/finger-touch icon for Access control.
Conditions are the inputs (what you monitor). Access controls are the actions you enforce. Together, they form Conditional Access rules.

​
Benefits

  • Customized access: Tailor policies by role (e.g., global admins vs. standard users), location, device posture, and risk.
  • Improved security: Require additional verification when sign-ins look risky (new location, unfamiliar device).
  • Single policy platform: Apply consistent controls across all Azure AD–protected apps.

​
Conditional Access flow recap

  1. User requests access to an app.
  2. Azure AD evaluates signals (user, group, app, device state, location/IP, client app, sign-in risk).
  3. Conditional Access policies that match the signals are evaluated and an outcome is enforced: Allow, Require MFA, or Block.
Think of it like programming logic: if conditions are satisfied, then take the configured action.

​
Portal walkthrough: create a Conditional Access policy

Below is a step-by-step example to create a policy that blocks a single user (Abigail) from accessing the Azure portal.
  1. Sign in to the Azure portal (portal.azure.com) as the account you will use to test (e.g., Abigail).
    • If MFA is required for that account, complete it during sign-in.
    • For demo/test tenants, use an incognito/private window to simulate specific users.
  2. Security Defaults
    • New Azure AD tenants enable Security Defaults by default. Security Defaults is a Microsoft-managed set of baseline security controls (including MFA for admins). You cannot create custom Conditional Access policies until you disable Security Defaults.
    • If you plan to manage your own policies, you must disable Security Defaults first.
Disabling Security Defaults enables custom Conditional Access policies but increases the risk of misconfiguration. Ensure you have protection for privileged/break-glass accounts (for example, keep an emergency admin secured with MFA) before turning it off.
  1. To disable Security Defaults:
    • Go to Azure Active Directory → Properties → Manage Security Defaults (at the bottom) and switch it off. Follow the prompts and save.
A screenshot of the Microsoft Azure portal showing the "Kodekloud | Properties" page with tenant details (name, country, tenant ID, contacts) on the left. A "Security defaults" sidebar on the right prompts the user to confirm disabling security defaults and choose a reason.
  1. Create the policy
    • Navigate to Azure Active Directory → Security → Conditional Access → Policies → New policy.
Example: Block Abigail from the Azure portal
  • Policy name: Block-Abigail-AzPortal
  • Assignments → Users and groups: select the target user(s) — e.g., Abigail.
A screenshot of the Microsoft Azure portal on the "New" Conditional Access policy creation page. The policy name "Block-Abigail-AzPortal" is entered, specific users are selected under assignments, and the policy is set to "Report-only" with a Create button visible.
  • Assignments → Cloud apps or actions: select the target app(s). For blocking access to the Azure portal, choose “Azure Management” (Azure Portal / Azure Resource Manager). You can target all cloud apps and exclude specific ones if necessary.
A screenshot of the Microsoft Azure portal showing the "New" Conditional Access policy page. The policy named "Block-Abigail-AzPortal" displays assignments, target resources and cloud app selection, plus enable-policy options and a Create button.
  • Assignments → Conditions: optionally set device platform, locations, client apps, sign-in risk, or user risk. In this demo we block Abigail regardless of platform or location, so no extra conditions are added.
A screenshot of the Microsoft Azure portal showing the Conditional Access "New" policy creation page. The Device platforms pane is open on the right, listing selectable platforms like Android, iOS, Windows, macOS, and Linux.
  • Access controls → Grant: choose the enforcement action. To block access, select “Block access.”
A screenshot of the Microsoft Azure portal showing the Conditional Access "New" policy named "Block-Abigail-AzPortal." The Grant pane is open on the right with "Block access" selected and various authentication/conditional controls listed.
  • Enable policy: policies can be created in Report-only mode to monitor impact. When ready, set the policy to On to enforce it and click Create.

​
Named locations and IP ranges

  • Define Named locations (countries or IP ranges) under Conditional Access → Named locations to reference trusted networks in policies (for example, office IP ranges).
  • Use Named locations with the Locations condition to whitelist or require extra controls when sign-ins originate from specific IP ranges or countries.
A screenshot of the Microsoft Azure portal on the Conditional Access → Named locations page, showing options to add country or IP-range locations and informational banners about IPv6. A “Creation has succeeded” notification is visible in the top-right.
After creation, review the Conditional Access Overview and policy tiles in the portal to confirm settings and scope.
A screenshot of the Microsoft Azure portal showing the "Conditional Access | Overview" page with navigation on the left and policy summary tiles (Users, Devices, Applications) in the main area. The top bar shows account and browser UI elements.

​
Testing and troubleshooting

  • End-user experience: when the policy is enforced, Abigail signing in to portal.azure.com will receive a message such as “You don’t have permission to access this resource” if blocked. The sign-in details show the Conditional Access policy that prevented token issuance—share this with support for faster troubleshooting.
A screenshot of the Microsoft Azure portal showing Conditional Access sign-in logs. The Activity Details pane on the right reports a failed sign-in with an error code and troubleshooting information.
  • Sign-in logs: view Azure AD Sign-in logs to see which Conditional Access policies applied and why a sign-in was allowed or blocked.
  • What If tool: Conditional Access → What If simulates a sign-in for a specific user, app, IP, location, device platform, client app, and risk level. It shows which policies would apply and whether access would be allowed—useful to validate policy impact before enforcement.
A screenshot of the Microsoft Azure portal showing the Conditional Access "What If" testing tool. The page displays fields for selecting a user/service principal, cloud apps, IP address, country, device platform, client apps, and sign-in/device risk options.

​
Best practices

  • Start in Report-only mode to monitor policy impact before enforcement.
  • Use the What If tool to validate conditions and avoid unintended lockouts.
  • Protect privileged accounts with stronger controls (MFA, dedicated break-glass accounts) before disabling Security Defaults.
  • Scope policies narrowly (target specific users or applications) rather than applying broad, tenant-wide blocks unless intentional.

​
Summary

  • Azure AD Conditional Access evaluates signals for each sign-in and enforces policies that Allow, Require MFA, or Block access.
  • Policies combine Conditions (when a policy applies) and Access controls (how access is enforced).
  • Use Named locations, device state, and Identity Protection risk signals to refine policies. Test with Report-only mode and the What If tool prior to enforcement to prevent accidental lockouts.
Next topic: Access reviews.

Watch Video