Intune Conditional Access Best Practices for Zero Trust Security

Conditional Access is the policy engine that makes Zero Trust work in Microsoft environments. It sits between your users and your resources and makes real-time access decisions based on identity, device state, location, and risk level. Get it right, and you have a security posture that adapts to threats automatically. Get it wrong, and you either lock out your workforce or leave gaps that attackers will find.

Here are the Conditional Access policies every Intune admin should have in place, along with the mistakes we see most often.

Policy 1: Require compliant devices for Office 365

This is the foundational policy. It says: you cannot access Exchange Online, SharePoint, Teams, or any M365 app unless your device is marked compliant in Intune. Compliance is defined by your Intune compliance policies (OS version, encryption, password requirements, threat level, etc.).

Why it matters: Without this policy, a user could access corporate email from an unmanaged personal laptop with no antivirus, no encryption, and outdated software. That is the most common attack surface in mid-market environments.

Common mistake: Applying this to "All cloud apps" on day one. Start with Office 365 apps only and expand gradually. If you apply it to all cloud apps immediately, you will block service accounts, break integrations, and generate a flood of helpdesk tickets.

Policy 2: Block legacy authentication

Legacy authentication protocols (IMAP, SMTP basic auth, POP3) do not support multi-factor authentication. They are the number one vector for password spray attacks. Create a Conditional Access policy that blocks all sign-in attempts using legacy authentication protocols.

Why it matters: Microsoft reports that more than 97% of credential stuffing attacks use legacy authentication. Blocking it is the single highest-impact security change you can make.

Common mistake: Forgetting about multifunction printers and line-of-business apps that still use SMTP basic auth. Audit your sign-in logs before enabling this policy to identify any applications that rely on legacy protocols. Migrate them to modern authentication or create a narrow exception.

Policy 3: Require MFA for all users

Every user should be required to complete multi-factor authentication. Use the Microsoft Entra security default or a Conditional Access policy that requires MFA for all users accessing all cloud apps.

Why it matters: MFA blocks 99.9% of account compromise attacks. There is no other single control with this level of effectiveness.

Common mistake: Not excluding break-glass accounts. Always create at least two emergency access accounts that are excluded from all Conditional Access policies, secured with FIDO2 keys stored in a safe, and monitored with alerts for any sign-in activity.

Policy 4: Block access from untrusted locations

Define your trusted locations (office IP ranges, VPN exit points) and create a policy that either blocks or requires additional verification for sign-ins from outside those locations. For high-risk applications (admin portals, financial systems), consider blocking external access entirely.

Why it matters: Location-based policies add a layer of defense against credential theft. Even if an attacker has a valid username and password, they cannot sign in from an IP range you have not approved.

Common mistake: Making location policies too restrictive for a remote workforce. If your employees work from home, you cannot block all external locations. Instead, combine location signals with device compliance and risk level for a nuanced policy.

Policy 5: Risk-based Conditional Access

If you have Entra ID P2 licenses, enable risk-based policies. These use Microsoft's threat intelligence to evaluate sign-in risk (impossible travel, anonymous IP, password spray detection) and user risk (leaked credentials, anomalous activity) in real time.

Why it matters: Risk-based policies are adaptive. They do not inconvenience users during normal operations but automatically step up security when something suspicious is detected.

Common mistake: Setting risk policies to "block" instead of "require MFA" for medium-risk events. Blocking medium-risk sign-ins generates a lot of false positives, especially for users who travel frequently. Require MFA for medium risk and block only high risk.

How to test without locking yourself out

The single biggest fear with Conditional Access is creating a policy that locks out all administrators. Here is how to test safely:

1. Use report-only mode. Every Conditional Access policy can be set to "Report-only" before enabling it. In this mode, the policy evaluates sign-ins and logs what it would have done, but does not actually enforce anything. Run every new policy in report-only for at least one week.
2. Check the "What If" tool. In the Entra admin center, the Conditional Access "What If" tool lets you simulate a sign-in scenario and see which policies would apply. Test your admin accounts, service accounts, and a sample of regular users.
3. Exclude break-glass accounts from every policy. This is non-negotiable. Your emergency access accounts must be excluded from all Conditional Access policies.
4. Roll out in phases. Enable policies for a pilot group first. Use an Entra ID group for pilot users and scope the policy to that group. Expand to all users only after validating in production for at least a week.

Conditional Access configuration is one of the first things we audit in every new client engagement at BluetechGreen. If you are unsure about your current policies, our free assessment includes a complete review of your Conditional Access configuration with specific recommendations.