Step-by-Step Guide: Implement Azure AD Conditional Access for Zero Trust Security

Traditional perimeter-based security is no longer sufficient in today's distributed cloud environments. Zero Trust follows the principle of "never trust, always verify" - every access request is authenticated, authorized, and encrypted regardless of where it originates.

Azure AD Conditional Access is Microsoft's implementation of Zero Trust for identity and access management. It allows you to create policies that enforce access decisions based on signals such as user identity, device state, location, and risk level.

Prerequisites

Before implementing Conditional Access, ensure you have:

• Azure AD Premium P1 or P2 license - Most Conditional Access features require P1 (included in Microsoft 365 E3/E5)
• Global Administrator or Conditional Access Administrator role in Azure AD
• At least one non-admin user for testing policies
• Azure AD tenant with users already provisioned

Finding Conditional Access in the Azure Portal

Navigate to Conditional Access through the Azure portal:

1. Sign in to portal.azure.com
2. Search for "Azure Active Directory" in the search bar
3. Select Security from the left navigation
4. Click Conditional Access in the Security overview blade

[Screenshot: Azure Portal > Azure AD > Security > Conditional Access - showing the Conditional Access policies blade with existing policies listed]

The Conditional Access blade shows your existing policies, allows you to create new ones, and provides quick access to the What-If tool for testing policies.

Creating Your First Policy: Require MFA for Admins

One of the most impactful policies is requiring multi-factor authentication for all administrative users. Here's the step-by-step:

# For reference: The Azure AD PowerShell module approach
# But we'll use the portal for this tutorial

Connect-AzureAD
New-AzureADMSConditionalAccessPolicy -DisplayName "Require MFA for Admin Users"

Follow these steps in the Azure portal:

Step 1: Create a New Policy

1. Click New policy from the Conditional Access blade
2. Give it a descriptive name: "Require MFA for All Admins"

Step 2: Assign Users

1. Under Users, select Directory roles
2. Choose the admin roles that require MFA:
   • Global Administrator
   • Exchange Administrator
   • SharePoint Administrator
   • User Administrator
   • Helpdesk Administrator

Step 3: Select Cloud Apps

1. Under Cloud apps or actions, select All cloud apps
2. This ensures MFA is required for all Azure services accessed by admins

Step 4: Configure Conditions

1. Under Conditions, you can add specific conditions:
   • Device platforms - Block or require MFA from specific OS
   • Locations - Require MFA from untrusted locations
   • Sign-in risk - Trigger on high/medium risk sign-ins
2. For now, leave conditions at default (none configured)

Step 5: Grant Access

1. Under Grant, select Grant access
2. Check Require multi-factor authentication
3. Click Select

Step 6: Enable the Policy

1. Under Policy settings, set Enable policy to On
2. Select Report-only if you want to test first (recommended)

[Screenshot: Conditional Access policy configuration - showing the full policy blade with MFA requirement selected]

Blocking Legacy Authentication

Legacy authentication protocols (IMAP, POP3, SMTP, older Exchange ActiveSync) don't support modern authentication and can bypass Conditional Access policies. Blocking these protocols is critical for Zero Trust.

Legacy auth is used by:

• Older email clients (Outlook 2010, older mobile apps)
• Third-party integration using basic auth
• Legacy device sync utilities

Step-by-Step: Block Legacy Authentication

1. From Conditional Access, click New policy
2. Name: "Block Legacy Authentication"
3. Users or workload identities: Select All users
4. Cloud apps: Select All cloud apps
5. Conditions: Configure Client apps:
   • Check Exchange ActiveSync
   • Check other legacy protocols as needed
6. Grant: Select Block access
7. Enable: Turn On (or Report-only to test)

The sign-in decision flow for legacy authentication:

┌─────────────────────────────────────────┐
│     User Attempts Legacy Auth              │
└──────────────────┬──────────────────────┘
                   │
                   ▼
┌──────────────────────���─���────────────────┐
│  CA Policy Evaluates                     │
│  (Client Apps = Legacy)                  │
└──────────────────┬──────────────────────┘
                   │
        ┌──────────┴──────────┐
        │                     │
        ▼                     ▼
┌───────────────┐    ┌───────────────────┐
│ Legacy Block │    │ Modern Auth        │
│ Policy ON?   │    │ Continues to       │
└──────┬────────┘    │ normal CA         │
       │             │ evaluation        │
       ▼             │
┌───────────────┐    │
│ BLOCK ACCESS  │    │
└───────────────┘

Named Locations

Named locations let you define trusted IP ranges (public IPs or ranges) and countries/regions that can be used in Conditional Access policies.

Creating a Named Location

1. In Conditional Access, click Named locations
2. Click New location
3. Configure:
   • Name: "Corporate Office IPs"
   • Type: IP ranges (or Countries/regions)
   • IP ranges: e.g., 203.0.113.0/24 (use your actual public IPs)
   • Mark as trusted location: Check this for office IPs
4. Click Save

[Screenshot: Named locations configuration showing IP ranges and country/region options]

Using Named Locations in Policies

You can use named locations as conditions:

• Include locations: Target users accessing from specific locations
• Exclude locations: Exempt trusted locations from MFA requirements

Example policy flow:

┌─────────────────────────────────────────┐
│       User Sign-In Attempt                 │
└──────────────────┬──────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────┐
│  Named Location Check                    │
└──────────────────┬──────────────────────┘
                   │
        ┌──────────┴──────────┐
        │                     │
        ▼                     ▼
┌───────────────┐    ┌───────────────────┐
│ Trusted IP?   │    │ Unknown Location   │
│ (Skip MFA)    │    │ (Require MFA or    │
│               │    │  Block)           │
└───────────────┘    └───────────────────┘

Authentication Context

Authentication Context (requires Azure AD P2) lets you create more granular access controls by marking sensitive apps and resources, then requiring additional verification when users access them.

Unlike standard Conditional Access policies that apply based on user/app, Authentication Context lets applications themselves signal their sensitivity level to Azure AD.

Step 1: Create Sensitivity Labels

1. Go to Azure AD > Security > Authentication contexts
2. Click New authentication context
3. Configure:
   • ID: "SensitiveApps"
   • Description: "Apps containing sensitive data"
   • Name: "Sensitive data access"
4. Click Save

Step 2: Create a Conditional Access Policy for Authentication Context

1. Create new Conditional Access policy
2. Name: "Require MFA for Sensitive Apps"
3. Target resources: Select Authentication context
4. Select your created authentication context(s)
5. Grant: Require MFA or other controls
6. Enable policy

Step 3: Apply Authentication Context in Apps

Apps must be configured to use Authentication Context. Here's how it works with SharePoint Online:

1. SharePoint Online admin center > Sensitive locations
2. Create a sensitivity label for the location
3. Under Require additional context, select your Authentication Context
4. Apply to sites or Teams that contain sensitive data

Similarly for custom applications using the Microsoft Graph API:

# MSAL.js example for requesting authentication context
const config = {
    auth: {
        clientId: "your-app-id",
        authority: "https://login.microsoftonline.com/your-tenant",
        // Request the authentication context claim
        claimsChallenge: '{"acrs":{"essential":true}}'
    }
};

Testing Your Policies

Always test Conditional Access policies before enabling them organization-wide. Azure provides two testing approaches:

What-If Tool

The What-If tool (available in the Conditional Access blade) lets you simulate policy evaluation:

1. Click What-If in the Conditional Access toolbar
2. Select a test user
3. Configure the scenario:
   • Target app (cloud app)
   • Device platform
   • Client app
   • IP address (simulate location)
4. Click What-If to see which policies would apply

[Screenshot: What-If tool showing policy simulation results]

Report-Only Mode

When creating or editing a policy, set Enable policy to Report-only. This lets the policy evaluate and log results without enforcing controls.

View report-only results in the Sign-in logs (Azure AD > Monitoring > Sign-in logs).

Dedicated Test Account

Create a dedicated test account:

• Add to pilot groups (not excluded from policies)
• Test on a non-admin device
• Clear cookies between tests

Common Pitfalls

Avoid these common implementation mistakes:

1. Locking Yourself Out

The most common mistake is creating a policy that blocks all users including admins.

Prevention: Always exclude at least one break-glass admin account from new policies.

2. Policy Conflicts

Multiple policies can conflict, causing unexpected behavior.

Prevention: Review the Effective view for each user to see all policies that would apply.

3. Exclusions Gone Wrong

Broad exclusions (like "All IT admins") can bypass your security policies.

Prevention: Be specific with exclusions. Use group membership, not directory roles.

4. User Training Gaps

New MFA requirements can cause support spikes if users aren't prepared.

Prevention: Communicate changes in advance. Register users for MFA before enabling policies.

5. Device Compliance

Device-based policies require Intune enrollment or hybrid Azure AD join.

Prevention: Ensure your device management is in place before requiring compliant devices.

6. Service Account Failures

Service accounts without MFA or running automated tasks can be blocked.

Prevention: Exclude service accounts (managed identities, service principals) explicitly.

Microsoft Recommended Practices

Microsoft recommends the following for Zero Trust Conditional Access implementation:

• Start with report-only mode - Always evaluate impact before enforcing
• Require MFA for all users - Especially admins, but eventually all users
• Block legacy authentication - Critical first step after MFA
• Require compliant devices - For sensitive resources
• Use session policies - For session duration limits
• Monitor sign-in logs - Continuous monitoring catches issues

For the SC-300 Identity and Access Administrator exam, focus on understanding:

• Policy assignment and targeting
• Grant controls (MFA, compliant device, terms of use)
• Session and persistence controls
• Authentication strength policies

See Microsoft Learn: Conditional Access documentation for the official documentation.

Conclusion

Azure AD Conditional Access is foundational to Zero Trust security. Start with these core policies:

1. Require MFA for all admins
2. Block legacy authentication
3. Require MFA from untrusted locations

As your implementation matures, add Authentication Context, device compliance requirements, and session controls for sensitive resources.

Remember: test in report-only mode, exclude break-glass accounts, and monitor sign-in logs. A phased rollout prevents disruptions while building Zero Trust security.

---

Last updated: May 6, 2026