Conditional Access is a Zero Trust if–then policy engine: if a sign-in meets certain conditions, then Microsoft Entra ID grants, blocks, or restricts access. Applied properly, it enforces MFA, device compliance, and session controls before anyone touches company data, which is why it’s the single most effective control most businesses can turn on this month.
TL;DR:
- Properly scoped policies should target specific user groups, applications, and device conditions to prevent accidental lockouts and minimize risk.
- Enforcing multi-factor authentication combined with device compliance offers the most effective protection against credential theft and account breaches.
- Starting with baseline templates like MFA for admins and blocking legacy protocols helps establish a strong security foundation with minimal disruption.
- Implement a staged rollout using report-only mode, small pilot groups, and thorough inventory to reduce support tickets and ensure smooth deployment.
- Regularly monitor sign-in logs and use the Insight workbook to detect misconfigurations, legacy authentication attempts, and evaluate policy effectiveness over time.
Table of Contents
- Conditional access basics: signals, phases and how policies get evaluated
- Assignments and conditions: scoping who, what, where and when
- Access controls: what you can actually enforce
- Common starter policies and templates to deploy first
- Planning, staging and safe deployment practices
- Monitoring, troubleshooting and measuring impact
- Practical checklist and the managed-support question
- Author perspective: what actually matters first
- Get Conditional Access set up properly, without the trial and error
- Sources
Conditional access basics: signals, phases and how policies get evaluated
Every Conditional Access policy runs on signals. The engine looks at who’s signing in, what device they’re using, where they’re connecting from, which app they want, and how risky Microsoft judges that sign-in to be, then makes a decision based on the combination.
The signals typically include:
- User and group membership — including role, so admin accounts can carry tighter rules than standard staff
- Device state — whether it’s enrolled, compliant, or completely unmanaged
- Location — named network locations, countries, or IP ranges
- Client app — browser, mobile app, or legacy protocol
- Sign-in risk — flagged by Entra ID Protection based on behaviour anomalies
Evaluation happens in two phases. First, Entra ID collects session data at the point of authentication. Second, it enforces whatever controls apply. This all happens after first factor authentication succeeds. It’s why Conditional Access isn’t a firewall or a denial-of-service shield. It evaluates authenticated attempts, not raw traffic, and it can’t stop someone from hammering your login page, only from getting past it.
Where things get interesting is when multiple policies apply to the same sign-in. Microsoft combines them with AND logic, meaning every applicable policy has to be satisfied. Miss that, and you’ll build conflicting rules without realising it.
Assignments and conditions: scoping who, what, where and when
A policy’s assignments define its reach, and getting this wrong is how admins accidentally lock out half the company on a Tuesday morning. Four things need deliberate scoping before you touch the “on” switch.
- Users, groups and roles. Start narrow. Target a pilot group or a specific admin role rather than “All users” on day one, and always check who’s excluded before you check who’s included.
- Target resources. Decide whether the policy applies to “All resources” (formerly “All cloud apps”) or specific applications. Broad targeting gives better coverage but higher blast radius if something’s misconfigured.
- Device filters and conditions. Use device state, platform, and filter expressions to differentiate managed corporate laptops from a personal phone checking email over lunch.
- Break-glass and service accounts. Document them, exclude them explicitly from restrictive policies, and store their credentials somewhere separate from the systems Conditional Access protects. If your only break-glass account gets locked out by the very policy meant to protect it, you’ve built a trap, not a safeguard.
Service principals and automated accounts deserve the same scrutiny. They don’t take MFA prompts well, so they usually need their own conditional exclusions or dedicated policies rather than being caught in a blanket rule meant for humans.
Access controls: what you can actually enforce
Once a policy identifies who and what it applies to, you choose the outcome: block or grant. Block is blunt, it stops access outright, and it’s usually reserved for legacy authentication or high-risk sign-ins. Grant is where the nuance lives.
Grant controls can require:
- Multi-factor authentication
- A compliant device, verified through Intune or a similar mobile device management platform
- An approved client app or app protection policy
- A specific authentication strength, such as phishing-resistant credentials for admin roles
You also choose whether the policy needs “require one” of those controls or “require all” of them, and that single toggle changes the user experience dramatically, as detailed in the Data Safety Summary — Clock-Me Mobile App. Session controls add another layer, limiting sign-in frequency, blocking persistent browser sessions on shared devices, or routing traffic through Conditional Access App Control for real-time monitoring.
Pro Tip: Requiring MFA is good, but pairing it with a compliant-device requirement is what actually blocks credential theft from unmanaged laptops. On its own, MFA still cuts account compromise risk by more than 99%, so even the simplest policy is worth deploying immediately.
For admin roles and anyone touching finance systems, push toward phishing-resistant or passwordless methods rather than SMS codes, which remain vulnerable to interception and social engineering.
Common starter policies and templates to deploy first
Microsoft ships templates specifically so you don’t have to design your baseline from scratch. The secure foundation set covers the moves every tenant should make early: require MFA for admins, require MFA for all users, secure security info registration, and block legacy authentication.
That last one carries outsized weight. Legacy protocols like POP, IMAP, and older versions of Exchange ActiveSync can’t support modern authentication challenges, and Microsoft reports over 97% of credential stuffing attacks and over 99% of password spray attacks rely on exactly this weakness.
Beyond the foundation set, Zero Trust and remote-work templates handle scenarios like requiring compliant devices for remote access or restricting sign-ins outside approved locations.
Microsoft-managed policies add a further layer of convenience: they can appear in your tenant automatically, already in report-only mode, ready to review and enable rather than built from a blank canvas. Use them as a starting point, not a finished product. Validate exclusions and pilot before switching anything to “On.”
Planning, staging and safe deployment practices
Rushing Conditional Access into enforcement is the fastest way to generate a flood of support tickets and an angry finance director locked out of payroll. A staged rollout avoids that entirely.
- Inventory first. Identify legacy clients, service accounts, and any app still using basic authentication.
- Create a break-glass account with a strong, unique credential, stored outside the systems you’re about to restrict.
- Run every new policy in report-only mode. Report-only lets you measure real-world impact before anyone is actually blocked, and the Conditional Access Insights workbook shows exactly who would have been affected.
- Pilot with a small group, expand gradually, then enforce for everyone. Communicate the change beforehand so the help desk isn’t blindsided.
A practical sequence that minimises disruption looks like this: inventory, create break-glass, run report-only on the block legacy authentication policy for a few days, resolve whatever shows up as high impact, pilot an MFA policy on a small group, then expand.
Pro Tip: Don’t skip the licensing check before you plan any of this. Full Conditional Access features require Microsoft Entra ID P1 or P2; tenants without either can fall back on Security defaults, which cover baseline MFA enforcement but offer none of the granular targeting described above.
Monitoring, troubleshooting and measuring impact
Sign-in logs are where every troubleshooting session starts. Filter by policy name and result, and you’ll see immediately whether a block came from Conditional Access or something else entirely, like a disabled account or an expired password.
The Conditional Access Insights workbook does the heavier lifting. It aggregates report-only results so you can see, at a glance, who would have been blocked, why, and whether the reason is legitimate risk or a misconfigured exclusion.
Common fixes worth checking first:
- Exclude temporary contractor or test accounts that don’t need the same restrictions
- Confirm the client app is classified correctly, since some legacy connections masquerade as modern auth
- Check device compliance state in Intune before assuming the policy itself is broken
Track legacy authentication attempts over time as a migration metric. Given that legacy protocols sit behind the overwhelming majority of credential stuffing and password spray attempts, a falling legacy-auth count is one of the clearest signs your environment is getting harder to breach.
Practical checklist and the managed-support question
Before enforcing anything, confirm you’ve: inventoried service principals, created a break-glass account, registered MFA methods for staff, run block legacy authentication in report-only, and piloted before rollout.
If your team has limited admin capacity, needs a formal SLA, or runs a complex hybrid environment, a managed partner earns its keep here. Managed partners build and monitor these policies for businesses needing expert help to get it right the first time.
Author perspective: what actually matters first
If you only do three things, block legacy authentication, require MFA for every admin account, and lock down access to admin portals specifically. Everything else is refinement.
Keep your policy count small and name each one so a stranger could understand its purpose in five seconds, because six months from now, that stranger will be you. Skip the temptation to build a dozen clever conditional rules before you’ve mastered the basics. Start with a short pilot on a handful of test accounts, watch the report-only data for a few days, then expand with confidence.
— Ru
Get Conditional Access set up properly, without the trial and error
Techbug is the alternative to trawling Microsoft documentation alone at 9pm trying to work out why report-only mode flagged forty accounts. We design, pilot, and monitor Conditional Access policies for Australian small and medium businesses as part of broader managed IT services, so the rollout gets done properly the first time instead of getting fixed after a lockout.
A typical engagement starts with an assessment of your current identity setup, moves into a piloted policy rollout with break-glass accounts protected from day one, and settles into ongoing monitoring so new risks get caught before they become incidents. That approach sits inside our broader IT security work, covering everything from Microsoft 365 hardening to endpoint protection. If you’re ready to move past the report-only stage without the guesswork, get in touch with Techbug for an assessment of where your tenant stands today.