Zero Trust identity and device access policies: the recommended Conditional Access set

Microsoft publishes a recommended set of Conditional Access, Intune app protection and device compliance policies for Microsoft 365, arranged in three protection levels: starting point, enterprise and specialized security. You can deploy the starting point policies in a fixed order, add device compliance when your devices are enrolled, and reserve always-on MFA for the users and data that justify the friction.

This article turns that guidance into a deployment plan. It covers the policy list, the licences each policy needs, the exclusions and groups to prepare, the Intune settings that sit behind the device policies, and a safe way to switch each policy on without locking people out.

Who this is for and what you will have at the end

This guide is for administrators who own identity and endpoint security in a Microsoft 365 tenant and want a known-good baseline instead of a pile of one-off Conditional Access policies. It assumes you are comfortable in the Microsoft Entra admin center and the Microsoft Intune admin center.

By the end you will have:

• A clear map of which policy belongs to which protection level.
• The groups and exclusions the policies depend on.
• Intune app protection and device compliance policies that Conditional Access can enforce.
• A rollout sequence using report-only mode, with a way to measure impact before enforcement.
• A checklist to confirm the baseline is complete.

If you are still deciding on a first control, start with the MFA rollout plan and come back here once users can register and use MFA.

The three protection levels

Microsoft's guidance applies the same idea at three levels, so protection for identities, devices and data stays consistent.

The levels are not separate products. They are the same building blocks with tighter thresholds and wider requirements. Microsoft's summary table shows how each protection mechanism changes by level:

Most organizations should apply the starting point to everyone, then use groups to apply enterprise and specialized policies to the people and data that need them. Microsoft's own example assigns the enterprise MFA policy to an executive staff group and the always-MFA policy to a single project group.

Prerequisites

Permissions

Use least privilege for the work:

• Conditional Access Administrator to create and edit Conditional Access policies.
• Intune Administrator to create app protection and device compliance policies.
• Security Reader if someone only needs to view the configuration.

For the role mapping beyond this baseline, see least-privilege Entra admin roles.

Licensing

Not every policy is available in every plan. The risk-based policies depend on Microsoft Entra ID Protection, which needs Microsoft Entra ID P2.

If your tenant lacks the P2-level licences, Microsoft recommends security defaults, which are available in all Microsoft 365 plans. Security defaults and Conditional Access policies that enforce the same control should not be mixed up; plan which one you are using before you start.

MFA registration comes first

Users must register for MFA before a policy requires it. If your licences include Entra ID P2, you can use the MFA registration policy in Microsoft Entra ID Protection to require registration. Microsoft also recommends requiring MFA before users enrol devices in Intune, so you know a device is with the intended person.

Groups

Create groups that map to the protection levels, for example one for executives and one for a specialized data set. Microsoft's guidance states that the groups used in these recommendations must be Microsoft 365 groups, not security groups, because of how sensitivity labels are deployed to secure documents in Teams and SharePoint.

Note a difference in assignment: Conditional Access policies can be assigned to users, groups and administrator roles, while Intune app protection and device compliance policies are assigned to groups only.

Emergency access accounts and the exclusion group

Every policy in this set should exclude two things:

1. Your emergency access (break-glass) accounts. These are for the case where all other administrators or authentication methods are unavailable, and their use should be monitored. See break-glass accounts and Conditional Access for a safe setup.
2. A Conditional Access exclusion group. It lets you grant a user access while you troubleshoot.

Treat the exclusion group as temporary. Microsoft warns that it should be monitored continuously for changes and used only for its purpose, and suggests access reviews in Microsoft Entra ID Governance to manage users excluded from Conditional Access policies.

If you use hybrid identity with Microsoft Entra Connect or Cloud Sync, the device compliance policy guidance also excludes the Directory Synchronization Accounts directory role. Service principals are not blocked by Conditional Access policies scoped to users, so use Conditional Access for workload identities if you need to target them.

Do not exclude applications from the baseline

Microsoft recommends a baseline MFA policy that targets all users and all resources, with no application exclusions. Applications such as Microsoft 365 and Teams depend on several services, so excluding one resource makes behaviour hard to predict.

There is also a recent enforcement change to know about. Microsoft's guidance notes that, rolling out between March and June 2026, Conditional Access policies that target all resources are enforced for sign-ins that request only OIDC scopes or a limited set of directory scopes, even when resource exclusions are present. If you have an all-resources policy with resource exclusions, review the affected sign-in flows, because users can see MFA or compliance challenges where they were previously allowed through.

Deployment order

Microsoft recommends implementing the starting point policies in this order. You can add the enterprise and specialized MFA policies at any time.

Starting point
  1. Require MFA when sign-in risk is Medium or High
  2. Block clients that do not support modern authentication
  3. High-risk users must change password
  4. Apply app protection policies (one per mobile platform)
  5. Require approved apps and app protection policies
 
Enterprise
  6. Require MFA when sign-in risk is Low, Medium or High
  7. Define device compliance policies (one per platform)
  8. Require compliant PCs and mobile devices
 
Specialized security
  9. Require MFA always

Do not roll every policy out to every app at once. Microsoft's advice is to decide which apps to protect, group apps that have the same protection needs, and add them incrementally: configure the policies for Microsoft 365 apps, add Exchange and work through issues, then Teams, then SharePoint, and continue until the starting point set covers all Microsoft 365 apps. Build a stricter set for sensitive apps, such as those used by HR or finance, the same way. Avoid policy sets that apply to all apps in a way that can lock administrators out of the Entra admin center or block exclusions for endpoints such as Microsoft Graph.

Step 1: Configure the starting point policies

Require MFA on elevated sign-in risk

Create the policy by following Microsoft's guidance for requiring multifactor authentication for elevated sign-in risk. Use these risk levels:

Assign the starting point version to all users, excluding emergency access accounts and the exclusion group. Assign the enterprise version to the group that needs the tighter threshold. Because this policy only fires when Entra ID Protection detects risk, it needs the P2-level licences listed above.

Block clients that do not support modern authentication

Clients that do not use modern authentication can bypass Conditional Access, so Microsoft recommends blocking them. Follow the legacy authentication blocking guidance. This policy is also what stops mobile mail clients from bypassing app protection. For the practical side, including printers and scanners that still send mail with basic authentication, read blocking legacy authentication without breaking printers and apps.

High-risk users must change password

Follow Microsoft's guidance for requiring a secure password change for elevated user risk, which makes users with compromised credentials change their password at sign-in. Microsoft recommends pairing it with Microsoft Entra password protection, which detects and blocks known weak passwords, variants and organization-specific terms, so the replacement password is stronger.

App protection policies

App protection policies state which apps may handle organization data and what they can do with it. Microsoft provides three data protection levels:

• Level 1, enterprise basic data protection: the minimum for enterprise devices.
• Level 2, enterprise enhanced data protection: for devices that access sensitive or confidential information; applies to most mobile users, and some controls may affect the user experience.
• Level 3, enterprise high data protection: for larger or more sophisticated security teams and for users at uniquely high risk.

Microsoft's tip is that most organizations should choose Level 2 (mapping to starting point or enterprise) and Level 3 (mapping to specialized security). Create one policy for each mobile platform in Intune, iOS/iPadOS and Android, either manually or by importing Microsoft's sample JSON templates with the Intune PowerShell sample scripts.

Require approved apps or app protection

An app protection policy does nothing on its own. Enforcement needs a Conditional Access policy as well: follow the guidance to require an approved client app or app protection policy. The result is that only accounts inside apps protected by app protection policies can reach Microsoft 365 endpoints on mobile devices. Together with the legacy authentication block, this closes the route around Conditional Access on iOS/iPadOS and Android.

Step 2: Enterprise level device compliance

Create the compliance policies

In the Intune admin center, go to Devices > Compliance > Create policy, and create one policy for each platform you support: Android, iOS/iPadOS and Windows 10 and later.

For mobile platforms, Microsoft maps the security levels to enrolment type:

As with app protection, Level 2 maps to starting point or enterprise and Level 3 maps to specialized security.

Windows 10 and later settings

Microsoft's recommended Windows compliance settings include the following, configured as described in the Intune Windows compliance settings reference:

Two settings need your own values. Under Device properties > Operating System Version, enter the minimum and maximum versions and valid builds that match your policy. Set Require device compliance from Configuration Manager to Required only in environments that are co-managed with Configuration Manager; otherwise leave it Not configured. Microsoft suggests keeping the Defender anti-malware minimum version no more than five versions behind the most recent.

If you are deploying BitLocker as part of this, see silent BitLocker encryption with Intune for the device side.

Devices must be enrolled in Intune before compliance can be enforced, so check enrolment coverage first.

Require compliant PCs and mobile devices

Only after the compliance policies exist and show compliant devices should you create the Conditional Access policy. Follow this configuration, which comes from Microsoft's device compliance policy page:

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Policies and select New policy.
3. Give the policy a name that follows your naming standard.
4. Under Assignments > Users or workload identities, include All users. Under Exclude, select your emergency access accounts and, for hybrid identity, the Directory Synchronization Accounts directory role.
5. Under Target resources > Resources (formerly cloud apps) > Include, select All resources (formerly 'All cloud apps').
6. Under Access controls > Grant, select Require device to be marked as compliant.
7. Set Enable policy to Report-only and select Create.

Microsoft warns that without a compliance policy in Intune this policy will not work as intended, and to verify that you have at least one compliant device, including your own, before enforcing. You can still enrol new devices to Intune when the policy applies to all users and all resources, because the control does not block Intune enrolment or access to the Microsoft Intune Web Company Portal app. It also does not block the Authenticator app from the UserAuthenticationMethod.Read scope it needs during registration.

Some details worth knowing:

• On iOS, Android, macOS and some third-party browsers, Entra ID identifies the device with a client certificate provisioned at registration. Users are prompted to select it the first time they sign in through the browser, and must do so to continue.
• If you use Windows Subscription Activation, exclude the Universal Store Service APIs and Web Application (App ID 45a330b1-b1ec-4cc1-9161-9f03992aa49f) from device compliance.
• For partner organizations you trust, you can trust their device compliance claims through inbound trust settings in cross-tenant access settings for B2B collaboration.

If you are not ready to require compliance for everyone, Microsoft lists intermediate options: require a compliant or hybrid joined device for administrators, require a compliant device, hybrid joined device or MFA for all users, block unknown or unsupported device platforms, and disable browser persistence. For deeper compliance troubleshooting, see requiring a compliant device with Conditional Access.

Step 3: Specialized security

For the small set of users or data that justifies it, require MFA always. Follow the guidance for requiring multifactor authentication for all users, and scope it to the specialized group.

Apply this carefully. Microsoft's own example notes that members of the project group must use MFA every time they sign in, even when they are not working on the specialized content, and that excess friction leads to fatigue. Phishing-resistant methods such as Windows Hello for Business or FIDO2 security keys reduce that friction.

Roll out safely with report-only mode

Every policy above should go through the same cycle: create it in report-only mode, review the results, then turn it on.

To set report-only on a policy, open Entra ID > Conditional Access > Policies, select the policy, and set Enable policy to Report-only. Be careful with existing policies: changing the state of an existing policy from On to Report-only disables its enforcement.

Measure the impact with the insights workbook

The Conditional Access insights and reporting workbook shows what policies would have done. It needs:

• A Log Analytics workspace that receives Entra sign-in logs.
• Microsoft Entra ID P1 for Conditional Access.
• At least the Security Reader role and appropriate Log Analytics workspace permissions.

Open it at Entra ID > Conditional Access > Insights and reporting. Policies appear in two groups, Enabled and Report-only. Pick your report-only policy, choose a time range (4 hours up to 90 days, limited to the time since log integration), and read the Impact summary:

Treat Failure for report-only policies as the list of people and apps you must fix or communicate with before enabling. Remember that report-only cannot determine success for interactive grant controls such as MFA, so those sign-ins show as User action required. If you need the data outside the workbook, download the sign-in logs in JSON format, which includes the report-only result data. Log retention setup is covered in sending Entra logs to Log Analytics.

Suggested rollout cycle

1. Create the policy in Report-only mode
2. Wait long enough to cover a normal work cycle
3. Review Failure and User action required in the workbook
4. Fix causes: unenrolled devices, legacy clients, missing MFA registration
5. Communicate to affected users
6. Switch Enable policy to On for a pilot group, then everyone
7. Keep the exclusion group empty and reviewed

Verification

After each policy is enforced, confirm it behaves as designed:

• Sign in as a test user in scope and check that the expected control is requested.
• If a result is not what you expect, work through Conditional Access What If troubleshooting.
• Re-open the insights workbook with the policy moved from Report-only to Enabled and confirm the Failure count matches your expectation.
• Check that the emergency access accounts can still sign in, and that any use of them raises an alert.

Troubleshooting

Checklist

• Emergency access accounts exist, are monitored, and are excluded from every policy.
• A Conditional Access exclusion group exists, is empty by default, and has a review process.
• Groups for enterprise and specialized levels exist as Microsoft 365 groups.
• Users have registered for MFA.
• MFA on medium and high sign-in risk is enabled for all users.
• Clients that do not support modern authentication are blocked.
• High-risk users must change their password, and Entra password protection is in place.
• Intune app protection policies exist for iOS/iPadOS and Android, and Conditional Access requires approved apps or app protection.
• Device compliance policies exist for each platform, and your own device is compliant.
• The compliant device policy ran in report-only mode and was reviewed in the insights workbook before being turned on.
• Always-on MFA is scoped only to the groups that need it.
• All-resources policies with resource exclusions have been reviewed for the 2026 enforcement change.

References

• Zero Trust identity and device access configurations
• Common Zero Trust identity and device access policies
• How to require device compliance with Conditional Access
• Conditional Access insights and reporting workbook