that will compare your existing Conditional Access configuration to what the ASD recommends and tell you what you should consider changing to bring your policies more in alignment with those from the ASD.
Above, you’ll see one policy evaluation and recommendation outputted to a HTML file for easy reading.
Implementing Conditional Access policies requiring device compliance in Microsoft 365 requires careful planning and a phased approach to minimize disruption while maintaining security. This comprehensive guide provides step-by-step instructions specifically tailored for small businesses.
1. Prerequisites and Initial Setup
Required Licenses
Microsoft Entra ID P1 or P2 – Required for Conditional Access
Microsoft Intune – Required for device compliance management
Microsoft 365 Business Premium or higher for small businesses
Essential Preparations
Configure Emergency Access Accounts
Create at least two emergency access (break-glass) accounts
Exclude these accounts from ALL Conditional Access policies
Store credentials securely and separately
Create Device Compliance Policies First
Define minimum OS version requirements
Set encryption requirements
Configure password/PIN requirements
Establish jailbreak/root detection settings
Enable User Registration for MFA
Allow users to register authentication methods before enforcing policies
Communicate registration requirements to all users
2. Phased Rollout Strategy
Phase 1: Foundation (Weeks 1-2)
Objective: Establish baseline security and prepare infrastructure
Create policies in Report-Only Mode
Block legacy authentication protocols
Secure the MFA registration page
Target privileged accounts first with phishing-resistant MFA
Phase 2: Pilot Testing (Weeks 2-4)
Objective: Test with limited user groups
Pilot Group Selection
Start with 5-10% of your organization
Include IT staff and willing early adopters
Avoid executives and VIPs initially
Ensure representation from different departments
Creating the Policy in Report-Only Mode
Navigate to Microsoft Entra admin center → Conditional Access → Policies
Create new policy with these settings:
Name: “Require Device Compliance – Pilot”
Users: Select pilot group
Cloud apps: Start with non-critical apps
Grant: Require device to be marked as compliant
Enable policy: Report-only
Phase 3: Gradual Expansion (Weeks 4-8)
Objective: Progressively include more users and applications
Automated Phased Rollout Approach
If using the Conditional Access Optimization Agent (requires Microsoft Security Copilot):
The agent automatically creates a 5-phase rollout plan
Groups are assigned based on risk and impact analysis
Automatic progression between phases based on success metrics
Risk-based Conditional Access policies provide adaptive security that automatically adjusts authentication requirements based on the risk level of sign-ins and user behavior, helping you maintain an optimal balance between security and productivity.
Prerequisites and Licensing
Microsoft Entra ID P2 license required for risk-based policies (includes Identity Protection)
Microsoft 365 Business Premium includes Conditional Access features for small businesses
Users must be registered for Multi-Factor Authentication (MFA) before policy enforcement
Configure trusted network locations to reduce false positives
Step-by-Step Implementation Guide
Phase 1: Foundation Setup (Week 1)
Create Emergency Access Accounts
Set up at least two break-glass accounts excluded from all policies
These prevent complete lockout if policies are misconfigured
Start with Report-Only Mode
Deploy all new policies in report-only mode first
Monitor for at least 7-14 days to understand impact
Review sign-in logs to identify potential issues
Phase 2: Sign-in Risk Policy Configuration
Navigate to Microsoft Entra admin center > Conditional Access
Create new policy: “Require MFA for risky sign-ins”
Configure settings:
Users: Include all users, exclude emergency accounts
Cloud apps: All cloud apps
Conditions > Sign-in risk: Select Medium and High
Grant: Require multi-factor authentication
Session: Sign-in frequency – Every time
Enable policy: Report-only (initially)
Phase 3: User Risk Policy Configuration
Create new policy: “Require password change for high-risk users”
Configure settings:
Users: Include all users, exclude emergency accounts
Cloud apps: All cloud apps
Conditions > User risk: Select High
Grant: Require password change + Require MFA
Enable policy: Report-only (initially)
Microsoft’s Recommended Risk Levels for Small Business
Sign-in Risk: Require MFA for Medium and High risk levels
Provides security without excessive user friction
Allows self-remediation through MFA completion
User Risk: Require secure password change for High risk only
Prevents account lockouts from overly aggressive policies
Users can self-remediate compromised credentials
Balancing Security and Productivity
Enable Self-Remediation
Sign-in risks: Users complete MFA to prove identity and continue working
User risks: Users perform secure password change without admin intervention
Reduces helpdesk tickets and minimizes productivity disruption
Azure AD Identity protection is available with Azure AD P2 and provides risk detection and policy enforcement for sign ins and users. It can also be incorporated with Conditional Access policies to provide even more flexibility. This video shows you the basics of Azure AD Identity Protection as well as showing you an example of a login process that generates creates risk.
There are situations with SharePoint Online where businesses wish to restrict users from downloading files. Unfortunately, this can’t be done at a document library level but I can be done at a user level provided you have licenses for Conditional Access.
Conditional Access is a features of Azure AD P1 and is included in SKUs like Microsoft 365 Business Premium. The above video takes you through the steps of configuring an appropriate Conditional Access policy in your environments to prevent downloads. The policy can be targeted at specific users and expanded to include other Microsoft 365 cloud services if desired.
I’ve now also created a video demonstrating how to automate Azure Conditional Access using PowerShell. As before, I am only making these scripts available via the CIAOPS Paton program.
In this video you’ll see me automatically backup up both Conditional Access locations and policies, then apply best practices locations and policies, finally restore the original policies, all using scripting.
One of the easy ways to protect your environment is to implement Conditional Access which is included with all Microsoft 365 plans. Otherwise, you can add Azure AD P1 to your environment to get this functionality.
This video will take you through the basics of setting up a Conditional Access including how to block access based on location. You’ll see how to create a Named Location, a Conditional Access policy and what it looks like when it is actually applied to a user.