Conditional Access in Microsoft 365: what it is and how to set it up
Last updated February 7, 2026
Microsoft 365 For many organizations, it is at the heart of their day-to-day operations. Email, files, and collaboration tools are available everywhere. That accessibility requires clear boundaries. Not every user, device, or location can automatically be trusted.
Conditional Access is the mechanism by which you establish those boundaries. It determines the circumstances under which someone is granted access to Microsoft 365 and linked applications. This is not done based on assumptions, but on concrete signals.
Exactly what Conditional Access does
Conditional Access is part of Microsoft Entra ID, formerly Azure Active Directory. It sits between logging in and actually using data and applications.
With each login, Microsoft assesses the situation. Who is trying to log in, from what device, from what location and with what risk profile. Based on that, it automatically decides whether to allow access, require additional authentication or deny access. You can think of Conditional Access as a continuous layer of control, not a one-time security measure.
Why Conditional Access is Needed
Traditional password-only security is no longer enough. Users work from home, on the road and on private devices. At the same time, accounts are increasingly being misused through phishing or leaked passwords.
Conditional Access makes it possible to tailor security to the situation. A user on a managed laptop in the office receives different treatment than someone logging in from an unknown device. This way you increase security without shutting everything down unnecessarily.
How Conditional Access is Structured
Each Conditional Access policy consists of set components that together determine what happens when you sign on. First, you determine to whom the policy applies and which applications are protected. Then you define under what circumstances the policy becomes active and what action follows.
That consistency is important. A strict access control policy without clear conditions quickly leads to frustration or blockages. Conversely, a lenient policy without controls offers little protection.
Setting up Conditional Access in Practice
Setting up Conditional Access requires structure. Always work step by step and test changes before enforcing them.
Access to Conditional Access
You start in the Microsoft Entra management center. There you go to Security and then to Conditional Access. This is the central place where all policies are managed. Make sure you work with an account that has sufficient permissions and that an emergency account exists outside of Conditional Access at all times.
Creating a new policy
Create a new policy and give it a clear name that describes its purpose. This seems like a detail, but with multiple policies, it prevents a lot of confusion. A name should make it immediately clear when and why the policy is being applied. This helps later on with management and error detection.
Choosing users and applications
Next, determine which users or groups are covered by the policy. It’s best to start with a small test group. This way, you can assess the impact without putting the entire organization at risk. Then, select the cloud apps. In many cases, this involves all Microsoft 365 services, but sometimes it makes more sense to start with a single application, such as Exchange or SharePoint.
Setting conditions and access control
Now you define when the policy becomes active. This could be, for example, logins from unknown locations, unmanaged devices or increased logon risk.
Then you determine what should happen when those conditions are met. Often that is mandating multi-factor authentication, but it can also mean that access is only allowed from a compliant device or that access is blocked completely.
Keep this combination manageable. Too many conditions and controls in one policy make behavior difficult to predict.
Test before you enforce
You don't fully enable a new policy right away. Put it in reporting mode first. In this mode, you see what the policy would do without actually blocking users or requiring additional steps. Check the login logs carefully. Adjust the policy as needed and only then permanently enable it.
Points of interest from practice
Conditional Access is powerful, but not forgiving. A wrongly set policy can have a big impact. Many problems arise from rules that are too broad, lack of exceptions for management accounts or an accumulation of policies that overlap. Regular review and cleanup is not a luxury, but necessary management.
Conditional Access at Mica IT
In practice, we see that Conditional Access works best when introduced incrementally. First a solid foundation, such as MFA for high-risk logins. Then refine it with device and risk conditions. At Mica IT, we set up Conditional Access in such a way that it remains understandable. Not only technically correct, but also logical for administrators and users.
Deploy Conditional Access quietly and thoughtfully?
Conditional Access is not a one-time setup, but an ongoing process. Properly set up, it grows with your organization and remains manageable.
Want to assess whether your current Conditional Access setup is logical and secure?
Frequently Asked Questions
Do I need a special license for Conditional Access?
Yes. Conditional Access requires Microsoft Entra ID P1 or P2. This license is included with Microsoft 365 Business Premium and most Enterprise subscriptions, among others.
Is Conditional Access mandatory if I use MFA?
No, but without Conditional Access, you cannot apply MFA contextually. Conditional Access determines when MFA is needed and when it is not.
Can Conditional Access restrict external users?
Yes. Guest users and external accounts can be included in policies. This is especially important when collaborating via Teams and SharePoint.
How do I avoid excluding myself?
By always excluding emergency accounts and testing new policies first in reporting mode. This is not an option, but a requirement.
How often should I evaluate Conditional Access?
At a minimum, when major changes occur in the organization or IT environment. In practice, a periodic audit, say quarterly, is prudent.
