Microsoft 365 Conditional Access Policies: Best Practices & Setup Guide UK 2026
Take the free IT Readiness Test and see where you stand, 10 quick questions.
What are conditional access policies and why they matter now
Conditional access policies are rules you set in Microsoft 365 that decide whether a user can access apps, data, or services based on real-time conditions. Instead of just asking "do you have the right password?", they ask "are you logging in from a trusted device? Is your IP in the right location? Are you using a modern browser?" If the answer to any condition doesn't match your policy, access gets blocked or requires extra verification.
The reason this matters in 2026 is simple: passwords alone no longer work. Attackers are faster than ever at stealing credentials, and traditional login methods leave too many gaps. The UK Government's National Cyber Security Centre (NCSC) now recommends conditional access as a core control for any organisation using cloud services. If you're a healthcare IT professional moving into Microsoft 365 administration, or an IT support team member looking to step up into cloud roles, understanding conditional access is no longer optional - it's a skill that makes you immediately more valuable.
Why UK organisations are tightening access controls now
Recent NCSC guidance and the ongoing rise of ransomware targeting UK public sector and NHS trusts has forced the pace. More organisations are now auditing who can access Microsoft 365, from where, and on what devices. The shift is real: by 2026, any organisation holding patient data, financial records, or sensitive customer information is expected to have conditional access policies in place.
For career changers from healthcare backgrounds, this is good news. Healthcare IT teams understand compliance pressure intimately. You already know why access controls matter. Conditional access policies are essentially a technical implementation of the safeguards your old teams relied on. The translation is straightforward: instead of physical security passes and manual logon sheets, you're writing rules that enforce the same thinking automatically.
Best practice 1: Start with a baseline policy for all users
Before you write clever rules, create a simple baseline policy that applies to everyone. This policy should require multi-factor authentication (MFA) for all cloud app access, from anywhere, on any device. It sounds harsh, but it's not: MFA is now the single most effective control against account compromise.
The baseline rule looks like this:
Why start here? Because it's non-negotiable. Even a user logging in from their secure home network still needs MFA. The overhead is minimal now that Teams, Outlook, and other apps cache credentials locally. Users authenticate once per device, then work normally. In practice, you'll see zero support tickets from this policy within two weeks.
Once this baseline is live and stable, everything else you do sits on top of it.
Best practice 2: Build location and device-based rules next
The second layer protects against the most common attack pattern: attackers stealing a credential, then logging in from an unexpected country or an unmanaged device.
Create policies that:
Example policy:
Run this in report-only mode for two weeks. Review the logs. Then enable it.
Best practice 3: Use identity risk detection for adaptive access
Microsoft Entra ID (formerly Azure AD) analyses login patterns in real time. It spots when someone logs in from an impossible location (e.g. London at 9am, then Tokyo at 9:05am), or when a user account suddenly starts accessing apps it never touched before. This is called identity risk.
Build a policy that responds to this:
When this policy triggers, the user re-authenticates. If they're legitimate, they pass. If it's an attacker, they fail because they don't have the actual password. The user barely notices (just one extra authentication), but you've blocked a real compromise attempt.
Best practice 4: Exempt service accounts and automation carefully
Service accounts, shared mailboxes, and integration accounts don't have users behind them. They can't do MFA. You'll need to exempt these from your baseline MFA policy, but do it with extreme care.
Instead of blanket exemption:
This way you're saying "yes, this account doesn't do MFA, but it can only operate in this narrow, auditable way."
Best practice 5: Plan for exceptions and use named locations
You will have legitimate exceptions: executives who travel, contractors who work remotely from partner offices, teams who occasionally need offline access. Don't solve this by weakening the baseline. Instead, use named locations.
A named location is a list of IP address ranges you trust: your office subnet, your VPN, or even a specific partner's network. You can then write a policy that says "if the user is on a named location AND logging in from a company device, don't require MFA" or "if the user is on a named location, allow legacy auth protocols."
This keeps your baseline strong while accommodating real business needs.
How to test and roll out safely
Never enable policies for everyone on day one. Use Microsoft's report-only mode. Set a policy to report-only for two weeks. Review what would have been blocked. Adjust. Then enable for 10% of users. Wait a week. Watch support tickets and logs. Then 50%. Then everyone.
This approach takes six to eight weeks but prevents the Friday 4pm panic call where half your organisation can't log in.
Want to move deeper into Microsoft 365 administration and security? Our Microsoft 365 Administrator Course dives into access controls, identity governance, and real-world policy implementation. It's currently on the waitlist (places open in early 2026), but you can join the priority list at smoothops365.com/courses to be notified first. Alternatively, if you're just starting your journey into IT administration, the IT Support and Cloud Fundamentals Course covers Entra ID basics and prepares you for this advanced work.
Frequently asked questions
What's the difference between conditional access and classic policies?
Classic policies are the old way of setting access rules in Azure AD. Conditional access is the modern, more powerful replacement. Conditional access lets you base decisions on real-time conditions like device compliance, location, and risk level. Microsoft is phasing out the classic model entirely by 2027, so all new implementations use conditional access. If you're setting up new policies today, always choose conditional access.
Can conditional access policies protect against phishing?
Not directly, but they make phishing attacks much harder to exploit. If an attacker steals a password via phishing, conditional access requires MFA, so the attacker still can't log in without the user's phone or authenticator app. Phishing attempts then trigger risk detections (unusual location, new device) which either block the attacker or force them to re-authenticate in front of the user. The combination dramatically reduces the window of time an attacker can operate.
Do I need to buy Microsoft Sentinel to use conditional access?
No. Conditional access is built into Microsoft Entra ID, which comes with most Microsoft 365 plans. Sentinel is optional and used for advanced threat detection and incident response. You can run effective conditional access policies without it. Sentinel helps you monitor policy effectiveness and spot trends, but it's not a prerequisite.
How often should I review and update conditional access policies?
Review quarterly at minimum. After any significant security incident (even at other organisations), review immediately. Update whenever your business changes (new office location, new partner access, shift to remote-first work). Also review whenever Microsoft releases new Entra ID features, because new capabilities often let you simplify or strengthen existing policies. Treat your policies as living documents, not "set and forget" rules.
What happens if a legitimate user gets blocked by a conditional access policy?
The user sees a message explaining they can't access the resource. Most of the time, it's actionable: "Your device is not compliant" means enrol in Intune, "Your location is blocked" means use a VPN, "MFA required" means authenticate again. For genuinely unavoidable cases (e.g. a user travelling to a blocked country), have an approval workflow: they request an exception, a security officer reviews, and you grant temporary exemption. Document every exception so you can spot patterns and tighten rules over time.
SmoothOps 365 runs live instructor-led training every Saturday and Sunday. 3 months. 50 contact hours. Keep your job while you train.