Conditional Access Templates: Uses & Best Practices

Microsoft is blocking 7,000 password attacks per second (Microsoft Digital Defense Report 2024). Its own telemetry records 600 million identity attacks per day. Yet a significant portion of Microsoft 365 tenants are still running without a single Conditional Access policy configured. The gap between threat volume and actual configuration is enormous.

A conditional access policy template is a pre-built if-then rule you can apply directly to your Microsoft Entra ID tenant — no need to construct every assignment, condition, and grant control from scratch. Templates exist for MFA enforcement, blocking legacy authentication, location restrictions, device compliance, and more.

You don't need all of them. The right set depends on your licensing tier (P1 vs. P2), your device mix, and your compliance requirements — SOC 2, ISO 27001, HIPAA, or others. The templates in this guide are mapped to those variables so you can pick the ones that fit your environment.

This guide covers what CA policies actually are, walks through ten templates by use case, provides a comparison table, explains what to watch for before you enable anything, maps templates to compliance frameworks, and shows where Trio MDM fits alongside Microsoft Entra ID.

TL;DR

What a Conditional Access Policy Actually Does

If you've already configured at least one CA policy in production, skip ahead to the template section below.

A conditional access policy evaluates five types of signals every time a sign-in occurs: user identity and role, device platform and compliance state, location (IP address or country), the application being accessed, and sign-in risk level (P2 licensing only). If those signals match the conditions you've set, the policy applies its grant control. If they don't match, it doesn't.

The grant control is what the user must satisfy — or face being blocked. Your options are: require MFA, require a compliant device, require a hybrid Azure AD joined device, require an app protection policy, or block access entirely. These conditional access policy examples cover the full range of what each policy can do, from a simple MFA prompt to a hard block.

Session controls are a lighter-touch option: you can set sign-in frequency (how often the user must re-authenticate) or disable persistent browser sessions, without fully blocking access. These are useful for unmanaged or personal devices where you want to limit the exposure window of a stolen session token.

Microsoft describes Conditional Access as its Zero Trust policy engine — the practical layer that sits between identity and access. Every sign-in passes through it. If any policy returns a block, the sign-in fails, regardless of what other policies allow.

One thing worth knowing before you touch any settings: every new CA policy is created in report-only mode by default. This is not a gap — it's the correct starting point. The policy evaluates sign-ins and records what would have happened, but doesn't enforce. You review the logs, confirm there are no unexpected blocks, and only then switch to enforcement.

If a sign-in is blocked and you can't tell which policy triggered it, open the Sign-in logs in Entra ID. The "Conditional Access" tab on each log entry shows exactly which policies applied and what each one returned.

The Conditional Access Policy Templates You Should Actually Deploy

Microsoft organizes its built-in conditional access policy templates into four categories, but the templates most IT teams actually need span licensing tiers and use cases. The list below maps each template to what it does, what it requires, and what breaks if you configure it wrong. These are organized by deployment priority — start at the top if you're building from scratch.

Some of these templates challenge the user (MFA prompt), some restrict access to specific conditions (compliant device, named location), and some are a straightforward conditional access deny access example — block and move on. Knowing which category a template falls into helps you sequence your rollout correctly.

Require MFA for All Users

This is the conditional access require MFA template most organizations should deploy first. It forces every user to complete multi-factor authentication before accessing any cloud resource, and it stops 99.9% of automated sign-in attempts.

• Assignments: All users (exclude your break glass account)
• Cloud apps: All resources
• Grant: Require multifactor authentication
• Licensing: Entra ID P1 (included in M365 Business Premium, E3, E5)

Note: Microsoft now enforces mandatory MFA for admin portals regardless of CA policy status, but you still need this policy for all users accessing non-admin resources.

If users are getting blocked instead of prompted for MFA, check that their authentication methods (Authenticator app, phone number, etc.) are registered. Unregistered users can't complete MFA and will fail the grant control outright.

Require MFA for Admins

A tighter version of Template 1, scoped specifically to privileged roles.

• Assignments: Select directory roles (Global Admin, Security Admin, and similar privileged roles)
• Cloud apps: All resources
• Grant: Require MFA
• Licensing: P1

If you've already deployed the all-users policy and it covers admins, this template is redundant in practice — but keeping it as a separate policy adds explicit visibility and makes it harder to accidentally exclude admins from the broader policy. Microsoft also deploys this automatically as a Microsoft Managed Policy for tenants without explicit CA configuration, so you may already have it.

Block Legacy Authentication

This is one of the most important conditional access block access policy templates you can deploy. It cuts off sign-in attempts using SMTP, POP3, IMAP, older Exchange ActiveSync, and Basic Auth — protocols that simply cannot perform MFA.

• Client apps condition: Exchange ActiveSync clients + Other clients
• Grant: Block access
• Licensing: P1

This is a direct conditional access deny access example: no challenge, no prompt — just a block. The CIS Microsoft 365 Foundations Benchmark v6.0.0 (Level 1, E3 — Control 5.2.2.3) explicitly mandates this policy.

Before enabling, audit your environment for legacy auth dependencies first. Use report-only mode and filter the sign-in logs by "Other clients" to find printers, scanners, older email clients, or service accounts still using these protocols. Auditing first is not a reason to delay — the risk of leaving legacy auth open is greater than the operational work of finding the dependencies.

If a service account or shared mailbox stops working after enabling this policy, open the sign-in logs for that account and look for client app type "Other clients" or "Exchange ActiveSync." Those entries are your legacy auth dependencies.

Require Compliant Device

Blocks access to cloud apps unless the device is marked compliant in an MDM solution (or meets hybrid Azure AD join requirements).

• Assignments: All users
• Cloud apps: All resources (or targeted apps)
• Grant: Require device to be marked as compliant
• Licensing: P1 for the CA policy itself; MDM enrollment required to generate a compliance state

If you're using an MDM solution like Trio MDM alongside Entra ID, device compliance state for Windows and macOS devices can be managed through the MDM platform before Intune policies apply.

One consequence that surprises most teams: enabling this policy means any unmanaged personal device — including a CEO's personal iPad — will be blocked from accessing work apps until it's enrolled. That often triggers an unplanned BYOD conversation that should have happened before the policy went live.

Block Access by Country or Region

Blocks all sign-in attempts from countries or regions outside your allowed list. This is the core conditional access policy location based template for organizations that have no operational reason for users to sign in from certain geographies.

• Locations condition: Include "All locations," Exclude named locations (your allowed countries)
• Grant: Block access
• Licensing: P1

Enable the "Include unknown countries/regions" toggle to catch IPs that can't be geolocated. For organizations wanting to conditional access block outside country sign-ins entirely, this template combined with that toggle gives you the most complete coverage.

One framing note: location is evaluated after first-factor authentication. CA is a sign-in filter, not a network firewall. It does not prevent someone from reaching your login page.

IP-Based Named Location Policy

This conditional access IP restriction policy works in two directions: skip MFA for users signing in from a trusted office IP range, or block all access from outside those trusted ranges.

• Create a named location with your office IP range(s) in CIDR notation (IPv4 and IPv6)
• Mark the location as trusted
• Then either: exclude the trusted location from MFA-required policies (skip MFA on trusted network), or include only trusted locations as allowed (block everything else)
• Licensing: P1

If your corporate network uses IPv6 egress, you must add IPv6 CIDR ranges to the named location definition. Omitting them means users on your office network will still get MFA prompts, because their sign-ins are arriving from an IP range that isn't in your trusted list.

Require App Protection Policy

Restricts mobile access to apps that have an Intune app protection policy applied. This is effectively a form of application whitelisting for mobile access — only apps your organization has approved and configured through Intune MAM can reach corporate data.

• Assignments: All users
• Client apps: Browser + Mobile apps and desktop clients
• Grant: Require app protection policy
• Licensing: P1 + Intune MAM. iOS and Android only.

This is also the conditional access approved apps only template to deploy if you're planning for BYOD mobile access without full device enrollment.

⚠️ Critical: The "Require approved client app" grant control is being retired June 30, 2026. Any policy using only that grant control will stop enforcing after that date. The migration path is to replace it with "Require app protection policy," which requires an Intune MAM policy already assigned to the target apps.

Sign-In Risk Policy

Evaluates real-time risk signals during sign-in — impossible travel, anonymous IP, atypical sign-in location — and challenges or blocks based on the risk level returned.

• Sign-in risk condition: Medium and above
• Grant: Require MFA
• Licensing: Entra ID P2 (M365 E5 or EMS E5)

If your organization is on E5 or has added P2 licensing, this policy adds a layer of automated risk response that MFA-for-all-users alone can't provide. Microsoft recommends migrating these from the legacy Identity Protection blade to a standard CA policy.

User Risk Policy

Responds to accumulated risk signals for a user account — for example, leaked credentials found in breach data — and forces a secure password change when risk reaches the high threshold.

• User risk condition: High
• Grant: Require password change
• Licensing: P2

Like the sign-in risk policy, this is a P2-only capability. For organizations already on that licensing tier, both risk policies together provide automated response coverage that static MFA policies miss.

Session Controls for Unmanaged Devices

For users accessing apps from personal or unmanaged devices, this template limits session persistence and sets a shorter re-authentication window.

• Filter for devices condition: Unmanaged (not joined to Entra ID, not enrolled in MDM)
• Session: Sign-in frequency (e.g., 1 hour) + Disable persistent browser session
• Licensing: P1

The biggest friction point with this template isn't technical — it's the help desk ticket volume from executives who can no longer stay signed in on their personal laptops. That ticket wave often delays enforcement by weeks, even after the policy is technically ready to go live.

Before You Enable Anything: Report-Only Mode and Break Glass Accounts

Treat this section as the conditional access policy checklist step that precedes every deployment — not a one-time setup task, but a gate you pass through before any policy goes from report-only to enforcement.

Report-only mode means the policy evaluates every sign-in and records what would have happened, without actually enforcing. Check the Sign-in logs in Entra ID, filter by the Conditional Access tab, and look for any users who would have been blocked unexpectedly. For small tenants, 48–72 hours of log review is a reasonable minimum. For larger or more complex environments, one to two weeks gives you time to surface service accounts, shared mailboxes, and legacy devices that only authenticate occasionally.

Break glass accounts are a separate requirement. Create at least two — cloud-only accounts with no MFA requirement, excluded from every CA policy. These exist purely as a last resort if a misconfigured policy locks out all administrators. Store credentials in a physical safe, not a password manager. Any sign-in from these accounts is an incident by definition, so monitor them for activity.

Before enabling any policy, ask: have you excluded break glass accounts? Have you reviewed report-only logs for at least 48 hours? Have you checked service accounts and shared mailboxes? If you can't answer yes to all three, the policy is not ready to enforce.

Managing multiple CA policies across a tenant is also a policy management challenge in its own right — once you have 15 or 20 policies, tracking overlaps, conflicts, and exclusion group membership requires a deliberate governance structure, not just a list of enabled policies.

The organizational barrier that most delays this step is time. IT teams rushing to check a compliance box before an audit often skip the report-only window entirely, and that's where most production outages originate.

Which Templates Map to Your Compliance Requirements

CA policies produce audit logs, sign-in records, and enforcement evidence. Which policies map to which framework depends on what your auditor is testing.

The breakdown below lists the templates that satisfy each framework's access control requirements. These are the policies your auditor will look for when reviewing your evidence set — report-only mode logs don't count as enforcement evidence, so make sure these are live before your audit window opens.

• SOC 2 (CC6.1, CC6.2): Logical access controls and authentication. Required templates: MFA for all users, MFA for admins, block legacy auth, require compliant device. The sign-in logs generated by these policies in enforcement mode are your CC6.1 evidence.
• ISO 27001:2022 (Annex A 8.2, 8.3): Identity management and privileged access. Required templates: MFA for admins, require compliant device, sign-in risk policy (P2 if available on your licensing tier).
• HIPAA: Access control and authentication safeguards. Required templates: MFA for all users, block legacy auth, require compliant device, and location-based policies if users access ePHI from outside the US. Note: The proposed HIPAA Security Rule NPRM (January 2025) — still in review as of July 2025 — would make MFA a formal statutory requirement if finalized. CA policies are the most direct way to satisfy this should it pass.
• GDPR: Access control for personal data. Required templates: location-based blocking for EU data residency scenarios, require compliant device.
• PCI DSS: Least-privilege access to cardholder data. Required templates: MFA for admins, IP-based named location (limit access to known IPs), block legacy auth.

None of these frameworks require a specific number of CA policies — they require evidence of access controls. Manual compliance mapping across multiple frameworks can be replaced with compliance automation tooling that handles the device configuration layer, leaving CA policies to handle the access control layer.

Free Conditional Access Policy Template

Download your Conditional Access Policy Template to get a structured, ready-to-use framework for defining and enforcing access controls. Use this resource to standardize your policies, apply conditions such as user roles, device compliance, and location, and strengthen your overall security posture.

Download Conditional Access Policy Template

Common Mistakes That Break Conditional Access Deployments

These failure modes are drawn from CyberCX's 2025 analysis of real client environments. Each one is avoidable with the right process — they show up repeatedly because teams move fast and skip steps.

• Policy overload: Too many overlapping policies create conflicts and make troubleshooting nearly impossible. The per-tenant maximum is 195 policies, but hitting double digits without a clear coverage map is already a management problem. Aim for the smallest number of policies that achieves your required coverage. The sign-in logs' Conditional Access tab is your fastest tool for surfacing conflicts — it shows exactly which policies applied to a given sign-in and what each one returned.
• Stale exclusions: Security groups are attached to CA policies to exempt certain users. Over time, users leave the organization or change roles, but nobody removes them from the exclusion group. These stale exclusions are a persistent security gap that doesn't show up in any dashboard. Audit exclusion groups on a quarterly basis.
• Forgotten scenarios: Guest users, service accounts, shared mailboxes, and unmanaged devices often fall outside the scope of policies targeting "All users." Test these account types explicitly against your policies in report-only mode before going live.
• Not migrating "Require approved client app": Any policy using only that grant control will stop enforcing after June 30, 2026. Migrating to "Require app protection policy" requires Intune MAM configuration for the target apps — app management tooling handles the mobile side of this requirement.
• Enabling policies without excluding break glass accounts: Covered in the report-only section above, but worth repeating here — this is the most common cause of tenant-wide lockouts. Set up break glass accounts before you enable anything.

If a user reports being blocked after a new policy was added, go to Entra ID Sign-in logs, find the failed sign-in, open the Conditional Access tab, and identify which policy returned "Failure." That's faster than reading through every active policy one by one.

How Trio MDM Fits Into a Conditional Access Deployment

Conditional access policy templates handle the identity side of Zero Trust — they evaluate who is signing in, from where, and under what risk conditions. But the "compliant device" signal that several of these templates depend on has to come from somewhere. An MDM solution is what writes that signal.

Trio MDM integrates directly with Microsoft Entra ID for identity and user management. Active users and groups sync from Entra ID into Trio MDM automatically, and Trio MDM acts as a supported SSO provider — enabling centralized identity management and automatic application of profiles, apps, and policies based on your company configuration. Trio MDM supports Android, iOS, iPadOS, macOS, Windows, and Linux.

Trio MDM's compliance automation feature automatically configures required security controls based on your selected compliance framework (CIS Level 1 or Level 2). For teams preparing for SOC 2 or ISO 27001 audits, Trio MDM covers the technical implementation domain for both frameworks — the device configuration layer that auditors test for security controls, separate from the non-technical requirements those frameworks also include.

When you configure the "Require compliant device" CA policy in Entra ID, the MDM solution you choose determines how device compliance state is written. Choosing your MDM layer is an upstream decision that affects every downstream CA policy using device conditions — get it right before you build those policies. Trio MDM is built for this role: enrollment, identity synchronization, and Entra ID integration are its core functions, not add-ons.

For organizations not yet committed to a device management platform, Trio MDM is designed as the primary MDM layer — enrollment, compliance enforcement, and Entra ID integration in one solution. If you're already fully deployed on a separate MDM, note that a single device cannot run two MDM solutions simultaneously. Plan your MDM strategy before configuring the "Require compliant device" CA policy, because the compliance state provider matters.

Ready to see how Trio MDM fits your environment? Start your free trial or book a demo to walk through the Entra ID integration with your specific device fleet.