Do you want MSAdvance to design and implement your Conditional Access policies without business “outages”?
Conditional Access is one of the most effective ways to reduce unauthorized access in Microsoft 365, Azure, and corporate applications… but it is also one of the easiest things to “break” if deployed without a method.
At MSAdvance, we apply a practical approach: baseline policies + pilot + report-only + telemetry + well-justified exceptions. This reduces risk without turning every sign-in into a support ticket.
- Definition of a Conditional Access baseline aligned with Zero Trust and user types (office, remote, frontline, third parties).
- Phased rollout (report-only → pilot → enforcement) with real business-process validation.
- Integration with MFA, Intune, Defender, and Purview so identity, device, and data work together.
Contact our team View Security & Compliance service
Related resources: MFA Guide for Entra ID · Practical Microsoft Intune Guide · Microsoft 365 Security Audit
Conditional Access is the policy “engine” in Microsoft Entra that decides whether a sign-in is allowed, blocked, or allowed with conditions (for example, MFA, compliant device, protected app, or location). In 2026, a realistic baseline usually includes 10 core policies: protect admins, enforce MFA gradually, block legacy authentication, control unmanaged devices, secure mobile with MAM, limit locations, reduce session exposure, and block device code flow except for justified use cases.
Quick summary: Conditional Access in 10 ideas (without breaking operations)
- Start with “anti-lockout” security first: emergency (break-glass) accounts, pilot, and report-only before enforcing anything.
- Start with administrators: strong MFA + shorter sessions in sensitive portals.
- MFA for everyone, but thoughtfully: gradual rollout, minimal exceptions, and user support.
- Cut the old stuff: blocking legacy authentication greatly reduces risk with low impact if done with proper inventory.
- Devices matter: where data is sensitive, require compliant devices (Intune) or limit access to web with restrictions.
- Mobile done right: MAM/App Protection for BYOD avoids lockouts and protects data.
- Locations: don’t block “the world” blindly; use countries/regions only if your business model allows it.
- Sessions: reduce persistence in critical apps (especially for admins).
- Device code flow: if you don’t need it, block it; if you need it, scope it tightly.
- Measure everything: Sign-in logs + insights workbook to see real impact and adjust without improvising.
Introduction: why Conditional Access matters more in 2026
Years ago, “enabling MFA” looked sufficient. Today, with token theft, more convincing phishing, and access from unmanaged devices, the question is no longer only “who are you?”, but also “where are you signing in from, with which device, and with what risk signals?”. This is where Microsoft Entra Conditional Access becomes essential: it lets you apply simple rules like “if X happens, then require Y” (for example, “if admin, require MFA and short session”).
And there is an important point: Conditional Access is not about “deploying many policies,” it is about deploying the right policies, in the right order, with a rollout that does not turn security into friction. This article gives you a solid foundation: 10 Conditional Access baseline policies that fit most organizations, with practical notes to keep business operations running.
Before you start: licensing, emergency accounts, and “safe mode”
1) Licensing: what do you need for Conditional Access?
To use Conditional Access (custom policies), the standard requirement is Microsoft Entra ID P1. Many organizations already have it included in plans such as Microsoft 365 E3 or Microsoft 365 Business Premium; if not, it can be licensed separately.
2) Two emergency (break-glass) accounts—or you will lock yourself out
Before enforcing policies, create at least two emergency accounts (securely stored, strong passwords, monitored access, exceptional use only) and exclude them from the most aggressive policies. They are your “airbag” if a condition applies where it should not (it happens more often than people admit).
3) A pilot group and the “report-only” habit
The safest way to roll out Conditional Access is to create a pilot group (representative users: IT, business, leadership, mobile workforce) and use report-only mode to see what would have happened before enforcing.
If you want an orderly baseline rollout (MFA + Conditional Access + user support), the MFA guide for Entra ID can also help.
Low-risk deployment methodology (report-only → pilot → enforcement)
In practice: a good policy badly deployed feels like a failure; an average policy well deployed feels like “everything still works.”
Phase A — Inventory
- Who is still using legacy auth?
- Which critical applications exist?
- How many people work mobile/BYOD?
- Which countries/locations are actually legitimate?
Phase B — Report-only
- Create policies from templates when applicable.
- Review impact in Sign-in logs.
- Identify necessary exceptions (the minimum).
Phase C — Enforcement
- Enable admins first.
- Then pilot users (business).
- Then broader rollout in waves.
Quick table: the 10 baseline policies (risk vs friction)
| Policy | What it reduces | Typical friction | License |
|---|---|---|---|
| 1. MFA for administrators | Privileged account compromise | Low/Medium | P1 |
| 2. Gradual MFA for users | Credential theft | Medium | P1 |
| 3. Block legacy authentication | Password spray / MFA bypass | Low (if inventory is good) | P1 |
| 4. Protect admin portals | Access to critical consoles | Low/Medium | P1 |
| 5. Compliant device for sensitive apps | Access from uncontrolled endpoints | Medium | P1 + Intune |
| 6. Unmanaged devices: restricted web only | Data exfiltration | Medium | P1 |
| 7. Mobile: App Protection (MAM) | BYOD data leakage | Low/Medium | Intune |
| 8. Locations: reduce attack surface | Access from “noisy” regions | Low/Medium | P1 |
| 9. Sessions in critical apps | Persistent tokens | Low/Medium | P1 |
| 10. Block device code flow | Authentication flow abuse | Low (except special cases) | P1 |
The 10 baseline Conditional Access policies (explained and operationalized)
In practice: every policy here has a clear objective. If you cannot explain it in one sentence, it is probably unnecessary or poorly designed.
Policy 1 — Require MFA (or phishing-resistant authentication) for administrators
If there is one policy that almost always deserves an immediate “yes,” this is it. Accounts with administrative roles are the most targeted, and when they fall, the impact is not “one mailbox,” it is your entire tenant.
- Scope: admin roles (Global Admin, Exchange Admin, SharePoint Admin, etc.).
- Applications: all apps, or at least admin apps (Admin Center, Azure, Intune).
- Control: “Require MFA” or, if your organization already uses FIDO2 keys / passkeys, phishing-resistant “authentication strength.”
Policy 2 — Gradual MFA for users (without punishing everyone on day one)
MFA for everyone is a good idea. The issue is how. If you enforce it with no preparation, support will collapse on Monday. If you roll it out in phases, business impact stays low and security improves significantly.
- Week 1: pilot (IT + advanced users + a couple of critical profiles).
- Week 2–3: departments with lower operational risk.
- Week 4: broad rollout and exception cleanup.
In this phase, user experience is what makes the difference: quick guide, reminders, support channel, and “what to do if I change my phone.” If you want to run this properly, use a baseline adoption and methods-registration guide.
Policy 3 — Block legacy authentication
Legacy auth (for example, older protocols without MFA) remains a common entry point for automated attacks. The good news: many organizations no longer use it “for real”… only leftovers remain. That is why this policy is so cost-effective: major risk reduction with manageable impact if inventory is done first.
- Before: identify who is using legacy auth (sign-in logs, reports).
- During: use report-only for a week to detect forgotten systems.
- After: block and document exceptions (if any).
Policy 4 — Protect admin portals (and shorten sessions where it matters)
Admin Center, Azure Portal, Intune… these are high-impact gateways. Here, stricter controls make sense: MFA always, plus less “endless” sessions.
- Grant control: MFA / authentication strength.
- Session controls: “sign-in frequency” to force periodic revalidation (based on your operations).
- Extra: block access from unmanaged devices if your IT model allows it.
If your organization has distributed IT teams or 24×7 shifts, tune this with the team: “more secure” should not mean “more pain.”
Policy 5 — For sensitive apps, require compliant devices instead of “trusting the user”
If sensitive data is involved (finance, HR, leadership, intellectual property), “username + password + MFA” is often not enough. This is where device posture comes in: access only from users who should have it, using devices that meet policy.
- Control: “Require device to be marked as compliant.”
- Requirement: Intune and compliance policies (PIN, encryption, minimum OS version, etc.).
- Smart application: do not apply it to everything; apply it where it is truly needed.
Policy 6 — Unmanaged devices: allow restricted web-only access (or block downloads)
This is very useful when the business needs flexibility (for example, suppliers, temporary staff, or BYOD you do not want to fully manage). Instead of blocking “just because,” you limit what users can do: view on web, but no downloads, no sync, no unrestricted copy.
- Goal: reduce data leakage in SharePoint/OneDrive/Exchange.
- Approach: “from unmanaged devices, limited experience.”
- Outcome: business keeps operating with lower risk.
Policy 7 — Mobile (BYOD) without drama: require App Protection (MAM) to protect data
Many people work from mobile devices. And not all those devices are corporate-owned. If your answer is “block all mobile,” the business will push back. The mature alternative is App Protection (MAM): protect data inside the app (PIN, encryption, no copy/paste to personal apps, etc.).
- Scope: iOS/Android.
- Control: “Require app protection policy.”
- Advantage: you do not need full device management to protect corporate data.
Policy 8 — Locations: reduce attack surface without “breaking” travel and remote work
Blocking countries can be useful… if your business truly does not operate there. But if people travel, you serve global customers, or your teams are distributed, aggressive location blocking becomes an exception factory.
Two approaches that usually work better than “block the whole world”:
- For unusual locations: require MFA (or higher authentication strength).
- Only block: countries/regions where you know legitimate work will never happen.
Tip: document why a region is blocked. If you cannot justify it in one sentence, it is probably not a good idea.
Policy 9 — Session controls: less persistence in critical apps (especially for admins)
It is not only about “login.” A session that lasts too long can become a gift if a token is stolen. Session controls help tune the balance: users should not authenticate every 10 minutes, but they should not have endless sessions where they do not belong.
- Sign-in frequency: useful in admin portals and sensitive apps.
- Persistent browser session: disable where long sessions do not make sense.
- Deployment: start with admins and critical apps; do not apply globally without impact measurement.
Policy 10 — Block device code flow (except narrowly justified scenarios)
Device code flow exists for devices with limited input capabilities (displays, shared devices, signage, etc.). The issue: it can also be attractive for abuse if not controlled. In 2026, the practical recommendation in many organizations is: block it by default and allow it only where strictly necessary.
- If you do not use it: full block.
- If you use it: allow only by very specific platform/location/group, with documentation.
- Rollout: use report-only first to detect “surprise” usage.
Bonus (highly recommended) — Require MFA for device registration or join
If users can register or join devices to Entra ID, requiring MFA for that action reduces abuse and unwanted enrollments. It is not always mandatory, but when applicable, it is usually a clean improvement.
Observability: how to know whether Conditional Access is reducing risk (and not just annoying users)
In practice: if you do not measure it, you will make decisions by gut feel, and that always ends with permanent exceptions.
What to review every week (especially during rollout)
- Sign-in logs: policy failures by app and client type.
- Which policies are truly applying: do not assume; verify.
- How many exceptions you are creating: if it rises quickly, something is poorly designed or poorly communicated.
Conditional Access workbook: your best ally for low-chaos rollout
Microsoft provides an insights and reporting workbook that helps you see policy impact over time: what would have been blocked, what is being blocked now, and where friction is concentrated.
Common mistakes (the ones that generate tickets and frustration)
1) Turning everything “ON” on day one
Conditional Access is not a light switch. Without report-only, without pilot, and without emergency accounts, it is only a matter of time before something critical stops working.
2) Excluding applications “just in case”
Resource exclusions often start as temporary… and then stay forever. If an app is excluded, you must define why, for how long, and what alternative will be implemented.
3) Blocking mobile with no alternative
If many users work from mobile, blocking without MAM/App Protection usually turns security into friction. The sensible approach is protecting data without requiring full device management when it is not necessary.
4) Overly aggressive location policies
“Block every country except mine” sounds good… until there is travel, roaming, suppliers, or remote teams. Better to require stronger MFA outside trusted locations, and block only where you are sure.
Operational checklists (before, during, after)
Before
- 2 break-glass accounts created and tested.
- Pilot group defined (representative).
- Inventory of legacy auth and critical apps.
- User communication plan (what changes, why, what to do).
- Policies created in report-only mode.
During
- Daily review of Sign-in logs (policy-related errors).
- User support (method registration, phone changes, etc.).
- Document exceptions and justify each one.
After
- Convert “temporary exceptions” into real remediation (or close them).
- Review policies quarterly (and after major changes: M&A, new apps, remote-work shifts).
- Set simple KPIs (legitimate block rate, tickets per user, etc.).
Frequently Asked Questions (FAQ) about Conditional Access
Does Conditional Access require specific licenses?
Microsoft Entra ID P1 is typically required to create and enforce Conditional Access policies. In many cases it is included in plans such as Microsoft 365 E3 or Microsoft 365 Business Premium. If not, Entra ID can be licensed separately.
What is the first policy I should enforce?
In practice, the most cost-effective first policy is usually “MFA for administrators.” It significantly reduces risk with manageable impact. From there, proceed with report-only and pilot for the rest.
How do I avoid locking out the entire company?
Use two excluded break-glass accounts, a pilot group, and report-only rollout before enforcement. Also use the “What If” tool and review Sign-in logs during the pilot.
What if I have many mobile users (BYOD)?
Instead of blocking, requiring App Protection (MAM) on mobile usually works better: it protects data inside the app without needing full device management.
Can blocking legacy auth break things?
It can, if older apps or devices still depend on legacy protocols. That is why report-only and a prior inventory are recommended: you can detect “leftovers” before enforcement.
Does it make sense to block device code flow?
If you do not use it, yes: it reduces abuse surface. If you do use it (for example, specific devices), allow it only for that narrowly scoped case and block it everywhere else.
How often should I review my Conditional Access policies?
At least quarterly, and always when relevant changes occur: new applications, new work model (remote/hybrid), mergers/acquisitions, or security changes (for example, incidents or new recommendations).
Official resources and external links
- Microsoft Entra Conditional Access (overview)
- Plan a Conditional Access deployment
- Conditional Access policy templates (common policies)
- Building Conditional Access policies
- Session controls (sign-in frequency, persistent browser)
- Conditional Access insights & reporting workbook
- What If tool
- Authentication flows (device code flow)
- Block authentication flows (device code flow)
- Microsoft Entra licensing (Microsoft Learn)
Related MSAdvance services: Security & Compliance · Modern Workplace · Licensing Procurement · All services
Conclusion and next steps
A good Conditional Access baseline is not measured by how many policies you have, but by two things: how much risk you reduce and how much friction you avoid. With these 10 baseline policies, deployed through report-only, pilot, and telemetry, organizations typically achieve real improvement without paralyzing the business.
Recommended next steps (fast and realistic)
- Create break-glass accounts and a pilot group.
- Build an inventory of legacy auth and mobility scenarios.
- Create all 10 policies in report-only and review impact.
- Enforce for administrators first, then pilot, then rollout waves.
Do you want MSAdvance to make it operational and documented?
We design and implement a Conditional Access baseline aligned with your business: minimum risk, minimum noise, maximum clarity.
