A Conditional Access policy is an if-then rule in Microsoft Entra: if a user tries to reach a resource, then they must meet a requirement first, such as multi-factor authentication (MFA) or a compliant device. Microsoft describes these policies as if-then statements run by its Zero Trust policy engine. This guide covers how the policies work, the baseline set most small and mid-sized businesses should start with, how to roll them out without locking anyone out, and what licenses you need.
TL;DR
- Conditional Access checks signals (who the user is, what device, where, which app, how risky the sign-in looks) and then blocks access or grants it with requirements like MFA or a compliant device.
- A sound baseline: secure MFA registration, require MFA, block legacy authentication, and require phishing-resistant methods for admins.
- Test every policy with a pilot group and in report-only mode before you enforce it.
- Entra ID P1 is the license floor. Risk-based policies need ID Protection, a P2 feature. Microsoft 365 Business Premium also covers Conditional Access features.
- Intune app protection policies and Conditional Access are two different tools that work together on mobile devices.
Table of Contents
- How a Conditional Access policy works
- Where to find and manage Conditional Access policies
- Conditional Access policy examples worth building first
- Conditional Access vs. Intune app protection policies
- Roll out in phases and test before you enforce
- What license do you need?
- Our perspective
- Get your policies built and kept current
- Common mistakes to avoid
- FAQ
- Sources
How a Conditional Access policy works
Think of Conditional Access as the checkpoint that sits after a user signs in with a password. Policies are enforced after first-factor authentication is completed, so they decide what happens next, not whether the password was right.
Every policy has two halves.
Assignments say who and what the policy applies to: users, groups, or agents; target apps; and conditions such as device platform, location, or risk level. Assignments are combined with a logical AND, so every configured assignment must be true before the policy triggers. A policy aimed at "all users" and "Exchange Online" and "outside the office" only fires when all three match.
Access controls say what happens when the policy triggers. The decision is either to block access or to grant it with requirements. Those requirements include MFA, authentication strength, a compliant or hybrid-joined device, an approved client app, an app protection policy, a password change, or accepting terms of use.
The signals behind each decision
Common signals include the user, group, or agent; IP location; device platform or state; the application being accessed; real-time and calculated risk; and Microsoft Defender for Cloud Apps signals. You pick the ones that matter for the question you are asking. A policy about travel cares about location. A policy about stolen credentials cares about risk.
One point trips up many admins. Conditional Access has no separate "allow" rule. A user who matches no policy is not blocked. Policies exist to block access or to add requirements when granting it, so gaps in your policy set are gaps in protection. That is why a deliberate baseline matters.
Where to find and manage Conditional Access policies
Admins with at least the Security Reader role can find Conditional Access in the Microsoft Entra admin center under Entra ID, then Conditional Access. Changing policies takes more: the Conditional Access Administrator or Security Administrator role.
The area has a few views worth knowing:
- Overview: a summary of recent activity, including how many policies are enabled versus report-only.
- Coverage: applications with and without policy coverage over the past seven days. Use it to find apps that no policy touches.
- Policies: the list where you create, edit, and turn policies on or off.
Check the coverage view after every new policy. It is the quickest way to see which apps still sit outside your rules.
Conditional Access policy examples worth building first
The best conditional access policies are rarely clever. They are the plain ones that close the most common doors. Microsoft's deployment guidance names baseline policies such as securing MFA registration, blocking legacy authentication, and requiring phishing-resistant methods for privileged users. Here is how that looks as a working set for a small business.
| Policy | Who it applies to | Decision |
|---|---|---|
| Require MFA for all users | All users, all cloud apps | Grant with MFA |
| Secure security-info registration | All users, during MFA registration | Grant only from a trusted location or compliant device |
| Block legacy authentication | All users, legacy client apps | Block |
| Phishing-resistant MFA for admins | Admin roles | Grant with a phishing-resistant authentication strength |
| Require compliant device for sensitive apps | Staff reaching company data | Grant with device compliance |
| Require approved apps or app protection on mobile | Users on iOS and Android | Grant with app protection policy |
| Block access from countries you never operate in | All users, selected locations | Block |
1. Require MFA for everyone
This is the single highest-value policy. Stolen passwords are cheap, and a second factor stops most simple account takeovers. If you are still turning MFA on user by user, read our setup guide for enforcing MFA in Microsoft 365 and our piece on why MFA matters for your business.
2. Block legacy authentication
Older protocols cannot prompt for a second factor, so an attacker who has a password can walk around your MFA policy through them. Block them with a dedicated policy, and use report-only mode first so you can see which old printers, scanners, or line-of-business apps still rely on them.
3. Protect the MFA registration step
If anyone can register a new MFA method from anywhere, an attacker with a stolen password can register their own phone. A policy that limits registration to trusted conditions closes that gap.
4. Require stronger methods for admins
Admin accounts are the prize. Require phishing-resistant methods for them, such as passkeys or security keys. Our guide to passkeys and phishing-resistant MFA explains the options and how users sign in.
5. Require a compliant device
A policy can require that the device is marked compliant or hybrid-joined before it opens company data. This keeps unmanaged personal laptops away from files and mail, which matters for manufacturers with design files and for law and dental offices with client records.
6. Add risk-based policies if your license allows
Sign-in risk and user risk policies respond to unusual behavior, such as a login from an unfamiliar location. They need ID Protection, covered in the license section below.
Conditional Access vs. Intune app protection policies
People searching for Intune app protection policies are usually trying to protect company data on phones without taking over the phone itself. The two tools are separate but connected.
- Intune app protection policies help protect organizational data on enrolled and unenrolled devices. They control things like copy and paste, saving to personal storage, and PIN requirements inside managed apps.
- Conditional Access decides whether a sign-in is allowed at all, and it can require an app protection policy as a grant control.
When you combine them, only client apps that support those protections can reach Exchange Online and other Microsoft 365 services. The result is that an employee can use Outlook on a personal phone, but company mail stays inside the protected app.
Two practical details from Microsoft's documentation. App-based access needs a broker app to register the device with Microsoft Entra ID: Microsoft Authenticator on iOS or Company Portal on Android. And creating the policy takes an Entra ID P1 or P2 license plus the Security Administrator or Conditional Access Administrator role.
For wider data protection beyond sign-in, see our practical guide to data loss prevention in Microsoft 365.
Roll out in phases and test before you enforce
The fastest way to create an outage is to switch on a tenant-wide policy on a Monday morning. Microsoft's planning guidance recommends deploying in phases: foundation first, then core authentication, then advanced protection. That balances security gains against disruption for users.
A rollout that works for a small company:
- Inventory first. List your apps, your admin accounts, and the shared or service accounts that cannot do MFA.
- Create break-glass accounts. Keep at least two emergency admin accounts excluded from policies, with strong unique credentials stored offline, so a bad policy never locks you out of the tenant.
- Build in report-only mode. Test with pilot groups and report-only mode before enforcement. Report-only logs what would have happened without blocking anyone.
- Review the results. Look for legitimate sign-ins that would have been blocked, then fix the cause or add a documented exclusion.
- Pilot with a small group. IT staff and a few willing users go first.
- Enforce in waves. Move department by department, and tell users what prompt they will see and why.
- Re-check coverage. Use the Coverage view to find apps outside your policies.
Document every exclusion with a reason and an owner. Financial firms and anyone facing audits will be asked for exactly that record.
What license do you need?
Microsoft Entra ID P1 is required for Conditional Access features. Risk-based policies need Microsoft Entra ID Protection, which is a P2 feature. The same page notes that customers with Microsoft 365 Business Premium can also use Conditional Access features, which is why many small businesses already own what they need and simply have not configured it.
If you are not sure what your tenant includes, our Microsoft 365 environment assessment reviews your licensing and configuration together.
Our perspective
We see the same pattern in small and mid-sized Wisconsin companies. They own Microsoft 365 Business Premium, which includes the tools for Conditional Access, and yet the policies are missing, half-built, or sitting in report-only mode for a year because nobody owns them.
Our view is that Conditional Access is not a project you finish. It is part of running identity as your perimeter. Devices move, staff change roles, vendors get added, and every change can open a gap. A baseline set once and never reviewed drifts out of date.
That is why we treat it as part of continuous, proactive infrastructure ownership rather than a one-time setup. Policy design, report-only testing, exclusion documentation, and coverage reviews belong in the same stack as monitoring and security, at a fixed cost per user, with no surprise project invoice each time something changes.
For manufacturers that cannot afford downtime, a careful phased rollout matters as much as the policy itself. For firms that face audits, a documented, reviewable policy set is evidence you can show. Both come from the same disciplined process.
Dustin Collett
Get your policies built and kept current
If you would rather not design, test, and maintain this yourself, we can do it with you. We start with an IT & Security Assessment that shows where your Microsoft 365 identity controls stand today, and our Managed IT Services keep them current under a fixed per-user model with 24/7 monitoring. Our Microsoft 365 consulting in West Bend serves businesses across Southeastern Wisconsin.
Ready to see where you stand? Book the IT & Security Assessment, or start with the free IT Risk Score, a 60-second check.
Common mistakes to avoid
- Skipping the break-glass accounts. One misconfigured policy can lock every admin out.
- Excluding too many users. Each exclusion is a hole. Keep them few, named, and reviewed.
- Leaving report-only on forever. Report-only logs but does not protect. Set a date to review and enforce.
- Forgetting guests and service accounts. Decide deliberately how each is handled.
- Relying on location alone. Location is one signal. Combine it with MFA and device state.
- No review cycle. Check the Coverage view and the sign-in logs on a schedule, not only after an incident.
For the bigger picture on why identity now matters most, see our article on identity-first security for SMBs.
FAQ
What is an example of a Conditional Access policy?
The most common example is "require MFA for all users on all cloud apps." The assignment targets everyone, and the grant control requires multi-factor authentication. Another common one blocks legacy authentication entirely.
Where do I find Conditional Access policies?
Open the Microsoft Entra admin center and go to Entra ID, then Conditional Access. Admins with at least the Security Reader role can view policies, and the Overview and Coverage tabs show activity and which apps have no policy.
Can Conditional Access lock me out?
Yes, if a policy is enforced without testing. Use report-only mode and a pilot group first, and keep emergency break-glass accounts excluded from policies. Microsoft's deployment guidance recommends this staged approach.
Do I need Intune to use Conditional Access?
No. Conditional Access works with Entra ID P1 or Microsoft 365 Business Premium on its own. Intune adds device compliance and app protection policies, which you can then require as grant controls.
What is the difference between Conditional Access and Intune app protection policies?
Conditional Access decides whether a sign-in is allowed and what it must satisfy. App protection policies control how company data is handled inside mobile apps. Used together, they limit access to apps that support those protections.