Conditional access policies are the rules that decide, at the moment someone signs in, whether they get into your Microsoft 365 data, and on what terms. In Microsoft Entra (formerly Azure Active Directory), each policy works as an if-then statement: if a user, device, app or location meets certain conditions, then access is granted, blocked or made subject to extra checks such as multi-factor authentication. This guide explains how they work, what licence you need, which policies to build first, and how to deploy them safely.
TL;DR
- Conditional Access is Microsoft’s policy engine for sign-ins: it reads signals such as identity, device and location, then allows, blocks or challenges access.
- It needs at least Microsoft Entra ID P1. Security defaults are the free alternative, but they cannot be customised and cannot run alongside Conditional Access.
- Start with a small baseline: MFA for everyone, legacy authentication blocked, compliant devices for company data, and tighter rules for administrators.
- Always exclude emergency (break-glass) accounts, run new policies in report-only mode and test with the What If tool before enforcing anything.
- Review sign-in logs regularly, because a policy set that was right a year ago may have gaps today.
Table of Contents
- What conditional access means in plain terms
- How a Microsoft Entra policy is built
- The licence question: Entra ID P1 or security defaults
- Practical examples of conditional access policies
- How to roll out a policy without locking anyone out
- Best practices that keep policies effective
- Common gaps we see
- Our perspective
- How LANCAST can help
- FAQ
- Sources
What conditional access means in plain terms
A password on its own proves very little. Credentials are phished, reused and sold, so the question “does this person know the password?” is no longer enough. Conditional Access adds context. It asks who is signing in, from what device, from where, to which application, and how risky the attempt looks, and only then decides what happens next.
Microsoft describes it as its Zero Trust policy engine, bringing signals together to make automated decisions and enforce organisational policy. The same page stresses the balance it is meant to strike: controls should apply when they are needed, without getting in the way of legitimate users doing their jobs.
A simple example makes it concrete. A member of your finance team signs in to Outlook from the office on a managed laptop: no extra prompt. The same account signs in from an unfamiliar country on an unknown device: the policy blocks the attempt, or demands MFA and a compliant device. Same person, same password, different outcome, because the context differs.
How a Microsoft Entra policy is built
Every policy has the same anatomy, which is worth understanding before you open the admin centre.
Assignments: who and what the policy covers
Assignments define the users or groups the policy applies to, the cloud apps or actions it targets, and the conditions that trigger it, such as location, device platform or sign-in risk. Be deliberate about exclusions here. The accounts you leave out matter as much as the ones you include.
Access controls: what happens when the conditions match
The grant controls decide the outcome: block access, or grant it on condition, for example requiring MFA, a device marked as compliant, or an approved client app. Session controls then limit what the user can do once inside, for instance restricting downloads from a browser session on an unmanaged device.
Why order of thinking matters
Policies are evaluated together, not in a queue. If several apply to the same sign-in, all their requirements must be met, and a block always wins. That is why a handful of clear, well-named policies is easier to manage than a sprawl of overlapping ones.
The licence question: Entra ID P1 or security defaults
This is the first thing most Irish businesses need to settle, and it is also what many people search for after seeing the feature in their portal and finding it greyed out.
Microsoft states that Conditional Access requires at least Microsoft Entra ID P1. Tenants without it can use security defaults, a free baseline that switches on a fixed set of protections. The trade-off is that security defaults have no customisation, whereas Conditional Access is fully customisable. The two cannot be used together: security defaults must be disabled before you create Conditional Access policies, as Microsoft’s deployment planning guidance also confirms.
In practice, the decision looks like this:
| Security defaults | Conditional Access | |
|---|---|---|
| Licence | None required | Microsoft Entra ID P1 or above |
| Customisation | None | Full control over users, apps, conditions and controls |
| Best for | Very small tenants with simple needs | Businesses that need exceptions, device rules or location rules |
| Can run together | No | No |
If you are a five-person business with no unmanaged devices and no special cases, security defaults may be perfectly adequate. Once you have contractors, shared mailboxes, service accounts, personal phones or a requirement to prove control to a customer or insurer, you will outgrow them quickly. Many Microsoft 365 business plans include the right Entra tier already, so check what you hold before buying anything. If you would like us to check it for you, our Microsoft 365 and cloud services team can review your tenant.
Practical examples of conditional access policies
The most useful policies are rarely exotic. The Irish National Cyber Security Centre’s Office 365 Secure Configuration Framework points to the same core set that most well-run tenants end up with.
Require MFA for all users
This is the single most valuable policy. It turns a stolen password into an insufficient one. Before you enforce it, make sure people have registered their authentication methods, or you will create a wave of support calls on day one. We have written a step-by-step checklist for moving to MFA in Microsoft 365 that covers registration and communication.
Block legacy authentication
Older protocols cannot perform MFA at all, so attackers target them precisely because they bypass your controls. Blocking legacy authentication closes that route. Check sign-in logs first to see whether any old scanner, application or mail client still depends on it, and fix or replace those before the block goes live. Scan-to-email on older office printers is a classic culprit.
Require compliant devices for company data
A policy can include the grant control that requires a device to be marked as compliant, so only machines meeting your security configuration can reach corporate resources. The NCSC framework describes this approach. Note that an Intune-enabled subscription is needed for the device compliance state to be managed and reported to Entra ID. If you are not yet managing devices, our Microsoft Intune setup guide is the place to start, and our guide to Windows Autopilot deployment shows how new laptops can arrive already enrolled.
Protect administrative access
The NCSC advises using Conditional Access to make sure only authorised privileged accounts can reach Azure management portals. Administrators hold the keys to everything, so they deserve stricter rules than everyone else: phishing-resistant MFA where possible, managed devices only, and no day-to-day email on admin accounts.
Restrict by location
If your staff only ever work from Ireland and a few known travel destinations, blocking sign-ins from unexpected countries removes a great deal of automated attack noise. Treat this as a filter, not a wall: attackers can use VPNs and local infrastructure, so location rules sit alongside MFA, never in place of it. Leave a documented process for staff who travel.
Special cases: meeting-room devices
Resource accounts for meeting-room hardware cannot answer an MFA prompt. Microsoft’s guidance for Teams Rooms suggests using dynamic groups to apply policies to those accounts and excluding them from user-interactive MFA. If you are planning a room rollout, see our notes on configuring Teams Rooms for reliable meetings.
How to roll out a policy without locking anyone out
The worst conditional access incidents are self-inflicted: an administrator enables a block policy for everyone, including themselves. Microsoft’s planning guide recommends a phased approach, and it works well for businesses of any size.
- Create two emergency access accounts. Cloud-only, with long unique passwords stored safely offline, and excluded from every Conditional Access policy. Both Microsoft and the NCSC stress this exclusion, because it is your way back in after a misconfiguration. Monitor their use, as any sign-in from these accounts should be rare and expected.
- Handle MFA registration first. A policy requiring MFA for people who have not registered will stop them working.
- Build the policy in report-only mode. The policy is evaluated at each sign-in and logs what it would have done, without enforcing it, so you see the real-world impact.
- Test with the What If tool. Microsoft’s What If tool in the Entra admin centre lets you simulate a sign-in for a chosen user, app and set of conditions, and shows which policies would apply. It is also the quickest way to troubleshoot when someone reports that they cannot get in.
- Pilot with a small group. Start with the IT team, then one department, then everyone. Test block policies before enabling them at scale.
- Enforce, then watch. Switch the policy to on, and keep an eye on sign-in logs for the first week.
Best practices that keep policies effective
Building the policies is half the job. Keeping them useful is the other half.
Name policies so a stranger can understand them. A naming convention that states the audience, the app and the control (for example, “All users, all apps, require MFA”) saves hours when someone else takes over the tenant.
Prefer fewer, broader policies. Overlapping rules are hard to reason about. Start from a baseline covering everyone and add targeted policies only where a real need exists.
Review the evidence. The NCSC and Microsoft both recommend monitoring sign-in logs and using the Conditional Access insights and reporting workbook to see how each policy performs and to spot misconfigurations. Put a recurring review in the calendar: quarterly is realistic for most small and medium businesses.
Pair access rules with sound credentials. Conditional Access decides who gets in, but weak or reused passwords still make attackers’ lives easier. Current NIST guidance on password verifier rules is a useful reference for length and screening, and our own password policy advice for Irish businesses turns it into something your staff can follow.
Do not treat it as the whole defence. Conditional Access protects the sign-in. You still need endpoint protection, email security and backup. Our Microsoft Defender review and business email security guide cover the layers around it.
Common gaps we see
Policies that look complete on paper often have holes. The patterns below are the ones to check for in your own tenant.
First, exclusions that were added “temporarily” and never removed. A contractor group excluded from MFA during a project can sit there for years. Second, service accounts and shared mailboxes that nobody owns, which fall outside the user-focused rules. Third, policies scoped to specific apps, leaving a newly added app unprotected. Fourth, report-only policies that were created, looked at once, and never enforced. Finally, a break-glass account that has not been tested since the day it was created.
The What If tool and the sign-in logs will expose most of these in an afternoon. That is why a periodic review matters more than a perfect first design.
Our perspective
When we start work with a new client, the Microsoft 365 tenant tells us a lot about how IT has been run. Where Conditional Access is in good shape, there are usually a few clear policies, a documented emergency account and an owner who knows why each exclusion exists. Where it is not, the tenant has often grown by accident: a licence upgrade here, a quick exception there, and nobody quite sure what is protecting what.
After thirty years of supporting Irish organisations, our view is simple. Conditional Access should be proactive, not a one-off project. The technology is the easy part. The lasting value comes from agreeing with the business what must be protected, rolling controls out in a way staff accept, and reviewing them as people, devices and apps change. A policy that users work around is no protection at all, so we spend as much time on communication and pilot groups as on configuration.
We would also say, plainly, that small businesses do not need to build everything at once. A sensible baseline of MFA, legacy authentication blocked, managed devices and protected administrator accounts removes the large majority of everyday risk. Add sophistication once that foundation is stable, and always keep your way back in.
— Carl
How LANCAST can help
As a Microsoft Cloud Service Provider, we design, deploy and monitor Conditional Access as part of our managed services, working alongside Intune device management, Defender and backup so the pieces fit together. We start with an assessment of your current tenant, agree a baseline with you, pilot it with your team and then keep reviewing it as part of ongoing support. You can see how our managed support for Irish businesses works, or look at our wider security services.
If you would rather talk it through, our IT consultancy and Microsoft 365 team can review your licences and current policies and tell you what to fix first.
FAQ
What licence do you need for Conditional Access?
You need at least Microsoft Entra ID P1. Without it, your tenant can use security defaults, which are free but cannot be customised. You cannot run both at once, so security defaults must be turned off before Conditional Access policies take effect.
What is the difference between Conditional Access and security defaults?
Security defaults apply a fixed baseline of protections with no options to change them. Conditional Access lets you define exactly who is covered, which apps are protected and what controls apply, including exceptions. It suits any business with contractors, personal devices or specific compliance needs.
Which Conditional Access policies should I create first?
Start with MFA for all users, a block on legacy authentication, and stricter rules for administrator accounts. Then add a requirement for compliant devices if you manage them with Intune. Create each in report-only mode and check the results before enforcing.
How do I avoid locking myself out?
Exclude at least one emergency access account from every policy, and test it periodically. Use report-only mode and the What If tool before turning on any block policy, and pilot with a small group first. Make sure MFA registration is complete before you require it.
Sources
- Microsoft Entra Conditional Access overview
- Configure security defaults for Microsoft Entra ID
- Plan your Microsoft Entra Conditional Access deployment
- The Conditional Access What If tool
- NCSC Ireland: Office 365 Secure Configuration Framework
- Conditional Access and compliance for Teams Rooms devices
- NIST password verifier rules