Conditional access is an if→then policy engine evaluated after a user clears first factor sign-in: if certain signals match (user, location, device, app), then a control applies (block, require MFA, require a compliant device). The one rule that separates a clean rollout from a support nightmare is sequencing: test every policy in report-only mode, keep at least two emergency access accounts excluded from every restrictive policy, and roll out in phases rather than switching everything on at once.
TL;DR:
- Most organizations should implement a small set of core policies, including requiring MFA for all users and blocking legacy authentication Protocols.
- Sign-in and device signals like location, app, and platform are useful but can produce false positives if relied on alone, emphasizing the need for multiple signals.
- Rolling out policies in report-only mode first and testing with a dedicated pilot group helps avoid unintentional lockouts and minimizes help desk tickets.
- Maintain at least two emergency access accounts excluded from all restrictive policies, regularly test their access, and monitor sign-ins to prevent being locked out themselves.
- Regular review of sign-in logs and policy impact metrics every quarter is essential to fine-tune policies and detect misconfigurations early.
Table of Contents
- What conditional access policies actually control
- How reliable are device and location signals?
- Which conditional access policies should every tenant have?
- How do you plan a phased conditional access rollout?
- Step-by-step: building and enabling a policy safely
- How do you avoid locking yourself out of your own tenant?
- How do you tune conditional access policies over time?
- What Techbug sees in real conditional access deployments
- Get your conditional access rollout done properly
- Sources
What conditional access policies actually control
Every conditional access policy has two working parts: assignments and access controls. Assignments define the “if” (who, what, where); access controls define the “then” (block, or grant with conditions). Conditional access policies are evaluated after first factor authentication, in two phases: Microsoft Entra ID first collects session details (user, device, location, app), then applies enforcement based on the matching policy.
Assignments break down into three questions:
- Who — specific users, groups, or directory roles (Global Administrator, for example)
- What — the cloud apps or auth contexts in scope, such as Exchange Online or SharePoint
- Where — named locations or IP ranges, used to distinguish trusted office networks from everywhere else
Access controls then decide the outcome. Block access is the blunt option, reserved for known-bad combinations like legacy authentication protocols. Grant access is more common and stackable: require MFA, require a compliant device, require an approved client app, require app protection policies, or require the user accept terms of use. Name policies consistently (“CA001: Block Legacy Auth, All Users” beats “New Policy (3)”) so anyone auditing the tenant later can read intent at a glance, a practice the ASD Blueprint specifically calls out as a low-effort, high-value control.
How reliable are device and location signals?
Signals are the “if” conditions your policies react to, and not all of them carry equal weight. Device signals identify whether a machine is compliant or Entra-joined, but browser private mode and user agent spoofing can occasionally mislead app-based detection, so device checks work best paired with a second control rather than standing alone.
- Location and IP — reliable for named locations and known office ranges, less useful against VPNs or mobile carriers that rotate IPs
- Client app — distinguishes browser, mobile app, and legacy protocols like POP and IMAP
- Device platform — iOS, Android, Windows, macOS, useful for platform-specific controls
- Filter for devices — targets policies at specific device attributes, handy for excluding kiosk or shared machines
- Sign-in risk — flags anomalous sign-ins (impossible travel, leaked credentials)
Sign-in and user risk signals require Entra ID P2 licensing; without it, risk-based conditional access simply isn’t available to you, and P1 covers only the core assignment and grant control model. Combining two moderate-confidence signals (location plus device) usually produces fewer false positives than relying on one signal alone.
Which conditional access policies should every tenant have?
A small, well-sequenced set of policies covers most of the risk. Practitioners commonly work from a baseline of around ten policies deployed across a few weeks, rather than dozens deployed at once, because fewer moving parts reduce the odds of an accidental lockout.
- Require MFA for all users — the foundational policy; covers the majority of account compromise attempts
- Block legacy authentication — closes off POP, IMAP, and older protocols that can’t enforce MFA
- Require phishing-resistant MFA for admins — privileged roles get stricter controls than standard users
- Require compliant device or app protection for Exchange and SharePoint — covers mobile and BYOD access to mail and files
- Block high-risk sign-ins and force secure password reset — requires P2, pairs risk detection with an automated remediation step
- Restrict guest access — tighter controls for external accounts touching shared resources
- Require compliant device for privileged access workstations (PAWs) — isolates admin activity to hardened endpoints
For unmanaged devices, resist the urge to block outright — see the Security & Trust · Semester Flow approach for examples of balancing session control and user experience. Session controls such as app-enforced restrictions or Conditional Access App Control can limit downloads or block copy and print actions instead, which keeps contractors and BYOD users productive without opening the tenant to data exfiltration risk.
How do you plan a phased conditional access rollout?
Before touching a single policy, confirm licensing. Entra ID P1 covers the core assignment and grant model; P2 is required for risk-based policies and Identity Protection integration. Check that Intune enrolment and app protection policies are in a workable state if your baseline includes device compliance or MAM controls, and confirm tenant health generally, since a messy directory makes every downstream policy harder to troubleshoot.
Microsoft’s own phased guidance breaks deployment into three stages:
- Secure the foundation (week 1 to 2): block legacy auth, secure MFA registration campaigns
- Core authentication (week 3 to 4): enforce MFA broadly, apply app protection policies
- Advanced protection (week 5 onward): risk-based policies, PAW enforcement, tighter guest controls
Run every new policy in report-only mode first, and use the What If tool to simulate specific sign-ins against your policy set before flipping anything live. Build a dedicated pilot group of test users, communicate the change window to staff, and don’t skip the internal announcement, since a wave of help desk tickets after a silent MFA rollout is entirely avoidable.
Pro Tip: Create a “policy testing” group and run report-only against it for at least a week before touching the wider tenant. Iterate on the false positive rate with that small group first, then expand scope once the numbers settle.
Step-by-step: building and enabling a policy safely
Treat every new policy as a small project with a defined rollback path, not a toggle you flip and forget.
- Draft the policy from a template using consistent naming (include a number, the control type, and the scope in the name)
- Set exclusions first — emergency access accounts and any known service accounts that can’t complete interactive MFA
- Save the policy in report-only mode and let it run against real traffic for at least a week
- Review the sign-in logs filtered to that policy, checking which users or apps would have been blocked
- Adjust conditions or exclusions based on what report-only surfaces, then re-run for a shorter validation window
- Enable enforcement for a pilot group before tenant-wide rollout
- Document the rollback action (disable the policy, or add a temporary exclusion) before you enable it broadly, so a stuck help desk ticket doesn’t turn into a scramble
Skipping step 3 is the single most common cause of unplanned lockouts admins report after a rushed rollout.
How do you avoid locking yourself out of your own tenant?
Maintain at least two break-glass accounts, cloud-only and built on your tenant’s default .onmicrosoft.com domain so they don’t depend on hybrid sync or directory replication. Register phishing-resistant MFA (FIDO2 security keys are the standard choice) for both accounts, and verify sign-in actually works before you enable any policy that could plausibly block them.
- Exclude both emergency accounts from every restrictive or blocking policy, not just the obvious ones
- Monitor sign-ins to these accounts and alert on any use, since they should almost never be touched
- Keep a documented rollback plan: disabling a policy or adding a temporary exclusion should take minutes, not a support ticket chain
Pro Tip: Test your break-glass accounts on a schedule, not just at initial setup. Credentials go stale, security keys get lost, and an emergency account that fails when you actually need it is worse than not having one.
How do you tune conditional access policies over time?
Report-only data and the What If tool tell you what would happen; sign-in logs tell you what did happen once policies enforce. Review the sign-in log filtered by “Conditional Access” status, watch failed sign-ins tied to specific policies, and track which apps or user segments generate the most blocked or interrupted sessions.
| Metric to track | Where to find it | What it signals |
|---|---|---|
| Failed sign-ins by policy | Entra sign-in logs | Overly strict conditions or misconfigured exclusions |
| Report-only policy impact | Conditional Access insights workbook | Whether a policy is safe to enforce |
| Blocked legacy auth attempts | Sign-in logs, client app filter | Remaining legacy app usage to migrate |
| User-reported access issues | Help desk tickets | Real-world friction not visible in logs |
Set a quarterly review cadence to reassess named locations, stale exclusions, and any risk-based policy thresholds, and treat every security incident as a trigger for an out-of-cycle policy review rather than waiting for the next quarter.
What Techbug sees in real conditional access deployments
Small businesses rarely fail at conditional access because the concept is hard. They fail because nobody owns the tenant full-time, so report-only findings sit unreviewed and emergency accounts get forgotten until the day they’re needed. Techbug’s vendor-agnostic managed services approach exists precisely for that gap: proactive monitoring catches a misconfigured policy before it locks out your finance team on payroll day, and staff training closes the human side that policy alone can’t fix.
The pattern we see repeatedly is a rushed all-users MFA rollout with no report-only phase, followed by a week of help desk chaos. A phased plan with a genuine pilot group avoids nearly all of it.
— Ru
Get your conditional access rollout done properly
Designing conditional access policies is one thing; running them correctly for years without an incident is another. Techbug manages this end to end for small and medium businesses, from the initial licence and tenant audit through report-only testing, phased enforcement, and ongoing monitoring, so nobody’s rushing an MFA rollout on a Friday afternoon.
Where a typical agency hands you a policy list and disappears, Techbug stays on as your emergency response team and monitoring partner once policies go live, which is where most conditional access problems actually surface. If you’re not sure whether your current setup has emergency access accounts properly excluded, or whether your tenant even has the right licensing tier for what you’re trying to enforce, that’s worth checking before you touch another policy. Get in touch with Techbug’s IT security team for a tenant audit and a practical rollout plan built around your current Microsoft 365 licensing and business risk.
Sources
- Build Conditional Access policies in Microsoft Entra
- Conditional Access – ASD’s Blueprint for Secure Cloud