Conditional Access Basics for Mid-Market IT Teams

Conditional access basics are the policies most mid-market IT teams reach for first when they decide to move beyond username-and-password as the only gate into Microsoft 365 and Entra ID. Done right, a small, well-understood set of conditional access policies blocks the vast majority of everyday account-compromise attempts without turning login into a daily obstacle course for your users. Done wrong, either by skipping it entirely or by copying a policy list from a blog post without understanding what each rule does, it becomes either a false sense of security or a source of constant help desk tickets.

This article walks through the conditional access policies that actually matter for a mid-market Microsoft environment, in the order most teams should build them, and where the common gaps show up once the initial policies are in place. It also looks at where conditional access stops and access governance starts, because the two are related but solve different problems.

What Conditional Access Actually Does

Conditional access is the Entra ID engine that evaluates a sign-in attempt against a set of conditions (who is signing in, from where, on what device, into which application) and then applies a control: allow, block, or require something extra like multi-factor authentication. It is not an access management system in the sense of deciding which groups or applications a user should belong to. It decides, at the moment of sign-in, whether that sign-in is allowed to proceed as requested.

Why it matters more than a strong password policy alone

Passwords leak. They get phished, reused across services, or guessed. A password on its own, no matter how complex the policy requires it to be, is a single point of failure. Conditional access adds context to the decision: a sign-in from a recognized device on the corporate network is a very different risk than the same username and password used from an unfamiliar location at 3 a.m. Conditional access lets you respond to that difference instead of treating every sign-in identically.

Licensing reality

Conditional access requires Entra ID P1 (included in most Microsoft 365 Business Premium and E3/E5 bundles). If your tenant is still on Microsoft 365 Business Standard or a similar plan without P1, this is usually the first licensing gap worth closing, since nearly everything below depends on it.

The Core Policies Every Mid-Market Tenant Should Have

Most mid-market environments do not need dozens of conditional access policies. A small, well-tested core set covers the majority of real-world risk.

1. Require MFA for all users

This is the single highest-impact policy available. Requiring multi-factor authentication for every user, on every sign-in unless another condition already grants a safer path, closes off the most common route attackers use once they have a stolen or guessed password.

2. Block legacy authentication

Legacy authentication protocols (older mail clients, some scripted connections) do not support modern authentication and cannot enforce MFA. They are a well-known bypass path for exactly the protection the MFA policy above is meant to provide. Blocking legacy authentication outright is standard practice at this point, not a bleeding-edge move.

3. Require compliant or hybrid-joined devices for sensitive access

For access to sensitive systems or data, requiring that the device itself is compliant (managed and meeting your security baseline through Intune) or hybrid Azure AD joined adds a layer beyond "the right person, with the right password and MFA code." It answers a different question: is this also a device you trust.

4. Require MFA for risky sign-ins specifically

Entra ID can flag sign-ins as risky based on signals like impossible travel, unfamiliar sign-in properties, or leaked credential matches. A policy that requires MFA (or blocks access outright) specifically on elevated risk adds a targeted layer on top of the baseline MFA policy, useful for organizations with Entra ID P2 and Identity Protection.

5. Block or restrict access from unmanaged devices for admin roles

Privileged roles deserve tighter conditions than standard users. Requiring a compliant device, and often a stricter MFA method, for anyone with an administrative role limits the blast radius if an admin account is ever targeted.

Recommended build order

Order	Policy	Why this order
1	Require MFA for all users	Highest impact, lowest friction to justify
2	Block legacy authentication	Closes the main MFA bypass
3	Require compliant device for sensitive apps	Needs Intune compliance baseline in place first
4	MFA for risky sign-ins	Needs Entra ID P2 / Identity Protection
5	Stricter controls for admin roles	Builds on device and risk policies above

Common Gaps After the First Policies Go Live

Getting the core policies in place is progress, but a few gaps show up repeatedly in mid-market tenants once the initial rollout is done.

Break-glass accounts excluded incorrectly

Every conditional access setup needs at least one break-glass account excluded from the policies, so a misconfiguration cannot lock every admin out of the tenant simultaneously. The gap is not having a break-glass account. It is forgetting to monitor it, so an account meant to be used only in an emergency sits unwatched.

Guest and external users left out of scope

Policies built around employee sign-in patterns often quietly exclude guest accounts or B2B collaboration users, either by oversight or because they were built before those accounts existed. Guests should generally be covered by at least a baseline MFA requirement, scoped appropriately for their access level.

Policies that were never revisited

Conditional access policies are usually built once, during a security push or an audit response, and then left alone. Roles change, new applications get added, and the policy set does not keep up. A short periodic review of what policies exist, what they cover, and what they were meant to prevent keeps the setup from drifting out of sync with the environment.

Conditional access treated as the whole access story

This is the gap most relevant to the rest of your identity setup. Conditional access controls whether a sign-in is allowed to happen. It has nothing to do with whether the user should have been assigned to that Entra ID group, that on-prem AD security group, or that application role in the first place. A perfectly configured conditional access policy will happily let a correctly authenticated user into an application they should never have had access to.

Where Conditional Access Ends and Access Governance Begins

Think of conditional access as the gate and access assignment as the guest list. Conditional access decides who is allowed through the gate right now, under these conditions. It does not decide who belongs on the list in the first place, or how long they should stay on it.

That second question, whether a user's group memberships and application access still match their actual role, department, and employment status, is an access governance problem, not a conditional access one. It requires:

• Group and role assignments that are kept accurate as people join, move, and leave.
• A way to see and periodically confirm who has access to what, and why.
• A defined process for removing access when it is no longer justified, not just blocking risky sign-ins to access that should have been revoked months ago.

Getting conditional access basics right closes off a large class of attacks. It does not, on its own, prevent access sprawl, where people accumulate group memberships and permissions over years of role changes that nobody ever cleans up. Both problems need attention, and they need different tools.

How ServiceChanger Fits In

ServiceChanger does not replace conditional access. It handles the layer conditional access was never designed to cover: making sure the access a correctly authenticated user actually has is the access they should have. The ABAC engine assigns users to Entra ID and on-prem Active Directory groups automatically based on attributes like department, location, and job title, so access stays aligned with someone's actual role instead of drifting as they change positions over time. Group mining surfaces the group structure already implied by existing access patterns, which is useful groundwork before tightening conditional access policies around sensitive groups. Built-in access reviews give you the periodic confirmation that group membership still makes sense, the same discipline conditional access relies on for device compliance and risk signals, applied to the group and role side of the picture instead.

For the broader picture of managing identity and access across Entra ID and on-prem AD, see our guide to identity and access management. For more on the security side of the picture, browse our Security articles, or see how attribute-based rules keep group membership accurate in our Access Control coverage.

FAQ

What is conditional access in Entra ID? Conditional access is a policy engine in Entra ID that evaluates sign-in attempts against conditions such as user, location, device, and risk level, and then applies a control such as allowing the sign-in, blocking it, or requiring multi-factor authentication. It decides whether a specific sign-in attempt is allowed to proceed, not which applications or groups a user should have access to.

What license do I need for conditional access? Conditional access requires Entra ID P1, included in most Microsoft 365 Business Premium and E3/E5 bundles. Advanced features like risk-based policies require Entra ID P2, typically included in E5 or available as an add-on.

What is the most important conditional access policy to start with? Requiring multi-factor authentication for all users on every sign-in is generally the highest-impact policy to put in place first, since it closes off the most common attack path once a password has leaked or been guessed. Blocking legacy authentication should follow closely behind, since legacy protocols bypass MFA entirely.

Does conditional access replace access reviews or group governance? No. Conditional access controls whether a sign-in is allowed to happen based on context like device and risk. It does not evaluate whether a user's group memberships or application access still match their role. That requires separate access governance practices, such as periodic access reviews and attribute-based group assignment.

If your conditional access policies are in place but you are less confident about what they are actually protecting on the group and role side, it is worth looking at the two together. Get in touch to see how ServiceChanger keeps Entra ID and on-prem AD access aligned with who people actually are.