Control who can access what, from where, and on which devices.
If you use Microsoft 365, your users authenticate through Microsoft Entra ID (formerly Azure Active Directory) every time they sign in. By default, that authentication is binary: either the credentials are correct and access is granted, or they are not and access is denied. There is no context, no nuance, no awareness of whether the sign-in is coming from a trusted office laptop in Edinburgh or a compromised device in a country where you have no employees.
Conditional Access changes this. It is Microsoft’s policy engine for identity-driven access control, and it sits at the centre of the Zero Trust security model that Microsoft has been building toward for the past several years. Rather than treating every authentication attempt the same way, Conditional Access evaluates a set of signals, applies the rules you have defined, and makes a decision: allow, block, or challenge. It transforms sign-in from a yes-or-no question into a contextual, risk-aware process.
For SMEs running Microsoft 365 Business Premium, Conditional Access is included in the licence. It requires Entra ID Premium P1, which Business Premium provides. Despite this, a significant number of small and mid-sized businesses have never configured a single Conditional Access policy. Their tenant is running with the defaults, which means every successful password entry grants full access to everything, from everywhere, on any device. This guide explains what Conditional Access does, why it matters, and how to implement it properly.
Why traditional access control no longer works
The old model was simple. Your network had a perimeter, and everything inside it was trusted. Employees worked from the office, on company machines, connected to the company network. Access control meant a firewall and a password.
Perimeter-based security
In the traditional model, trust was derived from location. If you were inside the office, connected to the corporate network, you were trusted. The firewall was the gatekeeper, and once you were past it, you generally had free rein. This worked when all users, devices, and data lived inside a single physical boundary. It does not work when your staff are spread across home offices, coffee shops, and client sites, accessing data stored in cloud platforms that your on-premise firewall has never seen.
Zero Trust and identity-first security
Zero Trust starts from the assumption that no user, device, or network should be inherently trusted. Every access request is verified independently, based on who is asking, what they are asking for, and the context surrounding the request. Identity becomes the new perimeter. Conditional Access is how Microsoft implements this principle across the Microsoft 365 ecosystem. It is the policy engine that evaluates every authentication attempt against your defined rules and decides, in real time, whether to allow, challenge, or block that access.
Signals: what Conditional Access evaluates
Every time a user attempts to sign in to a Microsoft 365 service, Conditional Access collects a set of signals about the request. These signals form the basis of every policy decision. The richer the signals available, the more precisely you can tailor your access controls to match the actual risk of each individual sign-in attempt.
User identity and group membership
At its most fundamental, Conditional Access knows who is trying to sign in. It draws on Entra ID to determine the user’s role, department, and group memberships. A finance controller accessing the company’s banking portal is a very different proposition from a marketing intern opening a shared calendar. The system understands this distinction and can apply different requirements accordingly. You can create policies that target specific security groups, making it straightforward to enforce stricter controls on users who handle sensitive data while keeping things frictionless for everyone else.
Device state and compliance
Conditional Access can evaluate the device being used to connect. Is it enrolled in Intune? Is it running an up-to-date operating system? Does it have disk encryption enabled? Is its endpoint protection active and reporting clean? These signals allow you to distinguish between a fully managed, compliant company laptop and someone’s personal tablet that has never been enrolled. For SMEs that have invested in Microsoft Intune, this is where that investment pays dividends: you can require device compliance as a condition of access, effectively ensuring that only properly configured machines can reach your data.
Location and network context
Every sign-in attempt carries an IP address, and Conditional Access can map that to a geography. You can define named locations, both trusted and blocked, that shape how policies respond. If your entire team is based in Edinburgh and nobody ever travels to Eastern Europe, why would you allow sign-ins from there? Location-based policies are one of the most effective tools for blocking opportunistic attacks, because most credential theft attempts originate from geographies far removed from where your actual users work.
Application being accessed
Not all applications carry the same risk. Accessing Microsoft Teams to check a meeting agenda is quite different from logging into the Azure portal with global admin privileges. Conditional Access lets you target specific applications with specific policies. You might require MFA for everything, but demand a compliant device only when accessing SharePoint, Exchange, or your line-of-business applications. This granularity means you can match the level of control to the sensitivity of the resource.
Real-time risk assessment
If you have Entra ID P2 licensing, Conditional Access can consume real-time risk signals from Microsoft’s Identity Protection engine. This evaluates sign-in behaviour against known patterns of attack: impossible travel (a sign-in from London followed by one from Lagos ten minutes later), sign-ins from anonymised IP addresses, credentials found in dark web data breaches. When risk is detected, the policy can escalate requirements automatically, requiring a password change or blocking access entirely without any manual intervention.
“A password tells you that someone knows the right credentials. Conditional Access tells you whether that person, on that device, from that location, at that moment, should actually be allowed in.”
Decisions: what happens next
Once Conditional Access has gathered its signals and evaluated them against your policies, it reaches a decision. There are three possible outcomes, and understanding the distinctions between them is essential for writing policies that are both effective and practical.
Grant with conditions
The most common outcome. Access is allowed, but only if the user satisfies one or more requirements: completing MFA, using a compliant device, connecting from a trusted location, or accepting the terms of use. You can combine conditions with AND or OR logic. For instance, you might require MFA and a compliant device for admin accounts, but only MFA for standard users. This flexibility is what makes Conditional Access so much more useful than a simple on-or-off switch.
Block access entirely
Sometimes the right answer is simply no. Block legacy authentication protocols that cannot support MFA. Block sign-ins from countries where you have no business operations. Block access from devices that are not enrolled. A well-configured block policy is one of the most powerful security controls available to you, because it removes entire categories of risk before an attacker even reaches the authentication prompt.
Session controls
For scenarios where you want to allow access but limit what users can do within the session, Conditional Access offers session-level controls. You can enforce sign-in frequency, so users must re-authenticate periodically. You can restrict browser sessions to prevent persistent cookies. With Microsoft Defender for Cloud Apps integration, you can even allow access to a cloud application while preventing file downloads, blocking copy-paste actions, or watermarking documents. These controls are particularly valuable for contractors or partners who need access to specific resources but should not be able to exfiltrate data.
Six essential policies for every SME
There is no single correct set of Conditional Access policies, because every organisation has different requirements, different risk profiles, and different licensing. However, these six policies represent what we consider the minimum viable configuration for any SME running Microsoft 365 Business Premium. They address the most common attack vectors and provide a solid foundation on which to build.
Block legacy authentication
This should be your very first policy, and it should be enforced without exception. Legacy authentication protocols, including POP3, IMAP, SMTP AUTH, and older versions of Exchange ActiveSync, do not support multi-factor authentication. They accept a username and password, and that is all. An attacker with a stolen credential can walk straight in. Microsoft has been deprecating these protocols for years, but many tenants still have them enabled because nobody has explicitly turned them off. A single Conditional Access policy that blocks all legacy authentication for all users eliminates this entire attack vector in one move.
Require MFA for all users
Every user, every sign-in, every application. No exceptions for convenience, no carve-outs because someone finds it annoying. Multi-factor authentication remains the single most effective control against credential-based attacks, and Microsoft’s own data shows it blocks over 99.9% of account compromise attempts. With Conditional Access, you enforce this at the tenant level rather than relying on individual users to enable it themselves. Use the Microsoft Authenticator app as the default method, and consider disabling SMS-based MFA where possible, as SIM-swapping attacks make it the weakest second factor.
Require compliant devices for sensitive apps
If you manage devices through Intune, you can require that only compliant devices can access your most sensitive applications. Compliance in this context means the device meets your defined baseline: operating system is up to date, disk encryption is enabled, endpoint protection is active, and no jailbreak or root has been detected. This policy is particularly important for applications that hold financial data, customer records, or intellectual property. It ensures that even if someone has valid credentials, they cannot access critical resources from an unmanaged or insecure device.
Block access from untrusted geographies
If your business operates exclusively in the United Kingdom and Ireland, there is no legitimate reason for sign-in attempts from Nigeria, Russia, or China. A location-based block policy eliminates a vast volume of credential stuffing and brute force attacks that originate from these regions. You define your named locations in Entra ID, mark your trusted locations (office IP ranges, VPN exit points), and then create a policy that blocks everything else. This single policy can reduce your sign-in noise by 80% or more and dramatically shrink the surface area that attackers can target.
Enforce stricter controls for admin accounts
Administrative accounts are the crown jewels. A compromised global admin account gives an attacker complete control over your entire Microsoft 365 tenant: email, files, identity, settings, everything. Your Conditional Access policies for admin roles should be significantly more restrictive than those for standard users. Require MFA on every sign-in with no trusted locations. Require a compliant device. Block access from anywhere outside your defined trusted IPs. Consider requiring phishing-resistant MFA methods such as FIDO2 security keys or Windows Hello for Business. The inconvenience to your administrators is trivial compared to the consequences of a compromised admin account.
Respond to risk-based signals
If you have Entra ID P2 licensing, enable risk-based policies that respond dynamically to suspicious activity. A medium-risk sign-in should trigger an additional MFA challenge. A high-risk sign-in should block access entirely and require a password reset before the user can continue. A user flagged as high-risk (their credentials have been found in a data breach, for example) should be required to change their password immediately. These policies operate in real time and catch threats that static rules cannot, because they respond to behaviour patterns rather than fixed conditions.
“Most SME tenants we audit have zero Conditional Access policies configured. The licence includes it. The capability is there. Nobody has turned it on. That single gap is often the difference between a secure organisation and a breach waiting to happen.”
How to implement safely
Conditional Access policies are powerful, and a misconfigured policy can lock your entire organisation out of its own systems. The implementation process matters as much as the policies themselves. Rushing this, skipping testing, or deploying too broadly too quickly is how outages happen. Here is the approach we use with every client, and it has never caused a disruption.
Audit your current state
Before you create a single policy, you need a clear picture of your existing environment. Review the Entra ID sign-in logs to understand how your users are currently authenticating. Which applications are they accessing? From what locations and devices? Are there legacy authentication attempts you did not know about? This audit almost always surfaces surprises: service accounts using basic authentication, users signing in from personal devices that are not enrolled, legacy applications that rely on protocols you assumed nobody was using. Understanding your baseline is essential, because you cannot write effective policies without knowing what you are working with.
Start with report-only mode
Every Conditional Access policy can be deployed in report-only mode before enforcement. In this mode, the policy evaluates every sign-in against its conditions and logs what it would have done, but does not actually block or challenge anyone. This is invaluable. Deploy your policies in report-only mode for at least two weeks and review the results carefully. You will discover edge cases you did not anticipate: the CEO’s personal phone, the shared reception account, the printer that authenticates via SMTP. It is far better to discover these in report-only mode than to enforce a policy that locks out half the company on a Monday morning.
Create a break-glass account
Before you enforce any Conditional Access policy, create at least one emergency access account that is excluded from all policies. This account should have a long, complex password stored securely (in a physical safe, not in a password manager that might be inaccessible if something goes wrong). It should have global admin privileges. It should be monitored for any sign-in activity. This account exists for one purpose only: to regain access to your tenant if your Conditional Access policies lock everyone out. It is your safety net. Without it, a misconfigured policy could leave you completely unable to manage your own environment.
Enforce policies in phases
Do not enable everything at once. Start with the policies that have the lowest risk of disruption: blocking legacy authentication (which should affect nobody if your audit was clean) and requiring MFA for administrators (who should already be using it). Once those are stable, move to MFA for all users, then location-based blocks, then device compliance requirements. Each phase should run in report-only mode first, then be enforced for a pilot group, then rolled out to the full organisation. This phased approach takes longer, but it virtually eliminates the risk of a catastrophic misconfiguration.
Document everything
For every policy you create, write down what it does, why it exists, who it applies to, and what exceptions are in place. This documentation is not bureaucracy for its own sake. When something breaks at nine o’clock on a Friday evening, you need to be able to quickly identify which policy is responsible and what changing it would affect. When a new IT administrator joins the team, they need to understand the logic behind your configuration without having to reverse-engineer it. When your auditor asks how access controls are managed, you need a clear, current answer. Good documentation turns a fragile, person-dependent configuration into a resilient, repeatable system.
Common mistakes to avoid
We have configured Conditional Access for dozens of SMEs, and the same mistakes appear again and again. Every one of them is avoidable. Every one of them has caused real disruption for organisations that did not take the time to get the fundamentals right.
No break-glass account
This is the mistake that causes the most damage, because by the time you realise you have made it, it is too late to fix. A misconfigured Conditional Access policy can lock every user out of your tenant, including every administrator. Without an emergency access account excluded from all policies, your only recovery option is a support ticket to Microsoft, which can take days. We have seen organisations unable to access their own email, files, or admin console for 48 hours because a well-intentioned policy change had an unintended scope. Create the break-glass account before you create your first policy. Not after. Before.
Skipping report-only mode
Confidence is not a substitute for testing. We have seen experienced administrators deploy policies directly to enforcement because they were certain they understood the impact. In nearly every case, something was missed. A shared mailbox that authenticates differently. A mobile app that uses legacy protocols. A service principal that does not support MFA. Report-only mode exists precisely for this reason: it lets you see the real-world impact of your policies without any consequences. Skipping it to save a few days of testing is a false economy that almost always costs more time in incident response than it would have saved.
Over-broad policy scope
A policy that targets ‘All users’ and ‘All cloud apps’ with no exclusions sounds thorough, but it is often reckless. Service accounts, shared mailboxes, meeting room devices, and third-party integrations all authenticate in ways that your user-facing policies may not accommodate. Apply policies to specific groups and pilot them before expanding scope. Use exclusion groups judiciously and review them regularly. The goal is comprehensive coverage, not careless coverage. A policy that blocks legitimate access is not a security improvement. It is an incident.
Ignoring the sign-in logs
Conditional Access policies are not a set-and-forget configuration. The Entra ID sign-in logs tell you exactly what your policies are doing: which sign-ins were blocked, which were granted with conditions, which satisfied MFA, and which failed. If you are not reviewing these logs regularly, you have no way of knowing whether your policies are working as intended. You will not notice the gradual drift as new applications, new users, or new devices are added without being covered by existing policies. Schedule a monthly review of your Conditional Access logs. It takes an hour and consistently surfaces issues that would otherwise go unnoticed.
Licensing and prerequisites
Conditional Access requires Entra ID Premium P1 licensing. For most SMEs, the simplest route is Microsoft 365 Business Premium, which includes P1 along with Intune device management, Defender for Office 365, and a range of other security features. If you are on Business Basic or Business Standard, you do not have Conditional Access and will need to upgrade or purchase standalone P1 licences.
Entra ID Premium P2 adds risk-based Conditional Access policies, which evaluate sign-in and user risk in real time. This is included in Microsoft 365 E5 or can be purchased as a standalone add-on. For most SMEs, P1 is sufficient to implement the six essential policies described in this guide. P2 becomes valuable when you want automated, dynamic responses to emerging threats.
Beyond licensing, the main prerequisite is that your users authenticate through Entra ID. If you are using Microsoft 365, this is already the case. If you have on-premise Active Directory synchronised via Entra Connect, Conditional Access policies apply to cloud authentication events. For organisations that have fully embraced the Microsoft cloud ecosystem, Conditional Access is the natural control plane for access management.
Why this matters for your business
Conditional Access is not an advanced feature reserved for enterprises with dedicated security teams. It is a fundamental control that every organisation using Microsoft 365 should have in place. The data speaks for itself.
of account compromise attacks are blocked by multi-factor authentication
in Microsoft 365 Business Premium. No additional licence cost for P1 policies
reduction in malicious sign-in attempts with location-based blocking policies
Need help with Conditional Access?
We design and implement Conditional Access policies for SMEs across the UK. That includes auditing your current tenant configuration, identifying gaps, building a policy framework tailored to your business, and deploying it safely through report-only testing and phased enforcement.
If you are running Microsoft 365 Business Premium and have not yet configured Conditional Access, a security review takes around an hour and will give you a clear picture of where you stand and what needs to happen next.