Block Microsoft 365 Apps with Conditional Access - Stepy by Step

Prerequisites

Before you start, verify every item below is in place. Missing even one can cause the policy to fail silently or lock out the wrong users.

• Microsoft Entra ID P1 or P2 license (or a trial) attached to the tenant.
• Admin account with the Conditional Access Administrator role (or Global Administrator) to create and edit policies. A Security Reader role is sufficient for read-only review.
• Windows devices registered in Microsoft Entra ID and assigned a valid license.
• A pilot group containing test users or devices, so you can validate the policy before expanding it to the entire organisation.
• At least one emergency access (break-glass) account that is documented, monitored, and excluded from the policy.

The CISA SCuBA baseline for Microsoft Entra ID mandates that any new Conditional Access policy start in Report-only mode before switching to On, to prevent unintended consequences. Follow that pattern throughout this guide.

For a related hardening task you can pair with this policy, see the ASR Rules Deployment: Step-by-Step Guide for Sysadmins.

Step 1: Open the Conditional Access Policies Blade

Sign in to the Microsoft Entra admin center using an account that holds the Conditional Access Administrator or Global Administrator role. Navigate to:

ID Protection > Risk-based Conditional Access > Policies

Select New policy to open a blank policy canvas. Give the policy a descriptive name that makes its intent obvious, for example Block-M365-Apps-Windows-Pilot. A clear name matters because Entra displays the policy name in sign-in logs, making troubleshooting far faster.

Step 2: Define User and Group Assignments

Under Assignments, select Users or agents. On the Include tab, add the Entra group that contains your pilot users. Avoid selecting All users during initial rollout.

Switch to the Exclude tab and add your emergency access or break-glass accounts. This single step prevents a total admin lockout if the policy is misconfigured. Microsoft's own emergency access guidance confirms that excluding break-glass accounts from every Conditional Access policy is a documented best practice. Skip this exclusion, and a misconfigured policy can lock every administrator out of the tenant simultaneously.

For step-by-step instructions on setting up break-glass accounts, see the Deactivate an Entra ID App Registration: Step-by-Step Guide for context on how Entra ID authentication controls interact.

Step 3: Specify Target Resources (Cloud Apps)

Under Target resources, select Resources (formerly cloud apps), then switch to the Include tab and choose Select resources.

You have two options depending on your organisation's requirements:

• Block the full M365 suite: Select the Office 365 app. This covers Teams, Exchange Online, SharePoint Online, OneDrive, and related services in one selection.
• Block individual apps: Search for and select specific services such as Office 365 Exchange Online or Office 365 SharePoint Online.

Note: Some resources display a "Resource unsupported in Conditional Access" message. Remove those from your selection before saving.

Blocking the full Office 365 suite is generally safer. Individual app dependencies, for example Teams relying on SharePoint for the Files tab, stay intact under a unified policy rather than breaking unpredictably.

Step 4: Set Device Platform Conditions

Under Conditions, select Device platforms. Toggle the configure switch to Yes, then pick the platforms this policy should apply to. A typical enterprise scope includes both Windows and macOS.

Conditions > Device platforms > Configure: Yes
Include: Windows, macOS

Conditional Access identifies the platform through user-agent strings the device provides. Select Done before moving on. If you need to manage the devices feeding into this policy through Intune, the Dell Management Portal for Intune: Integration Setup Guide covers device enrollment and compliance policy assignment.

Step 5: Choose Client App Types

Still under Conditions, select Client apps and toggle configure to Yes. Two categories matter under Modern authentication clients:

• Browser: Blocks access through any supported web browser.
• Mobile apps and desktop clients: Blocks the native M365 desktop and mobile applications.

Select both options to cover all access vectors. If your organisation only wants to restrict browser access while allowing managed desktop clients, select only Browser.

The CISA SCuBA baseline also requires blocking legacy authentication protocols via Conditional Access, because legacy protocols do not support MFA. Adding a separate policy for legacy auth closes that gap alongside the device-platform restriction you are building here.

Step 6: Configure the Block Access Control

Under Access controls, click Grant. You will see options to grant access with conditions or to block access outright. Select Block access.

Access controls > Grant > Block access

This is the enforcement action. Any user in scope who attempts to reach the targeted resources from a matching platform and client type receives an access-denied response. Confirm the selection and return to the policy summary screen.

Why Credential Theft Makes This Step Urgent

Stolen credentials are the reason device-gating matters. The Verizon 2025 DBIR found that 46% of compromised systems with corporate logins in their credential data were non-managed devices, most likely BYOD endpoints. Blocking unmanaged devices at the Conditional Access layer removes the path attackers rely on even when they hold valid credentials.

Threat actors who compromise Microsoft 365 environments sometimes abuse legitimate infrastructure for persistence. The DragonForce Abuses Microsoft Teams TURN Servers for C2 report shows why restricting which devices can authenticate to M365 services reduces attacker dwell time.

Step 7: Enable the Conditional Access Policy Safely

Report-Only Review

Do not switch the policy directly to On. Set Enable policy to Report-only first.

Enable policy: Report-only

In Report-only mode, Entra evaluates every sign-in and writes the outcome to the Sign-in logs without blocking anyone. In our test tenant, Report-only mode surfaced two service accounts within minutes of enabling the policy, accounts that would have been blocked and broken automated workflows. Review the logs carefully for any admin accounts or service principals appearing in the "Would be blocked" results.

Going Live

Once you confirm the scope is correct, return to the policy and switch the toggle:

Enable policy: On

Entra now denies access when an in-scope user tries to reach the targeted M365 apps from a non-compliant or unregistered device. Entra logs the block event against the correct policy name in the Sign-in logs, giving you a clear audit trail.

Verify Your Conditional Access Block Policy

Test the policy from a device that matches your defined conditions before expanding the rollout.

• Sign in to a Windows device that is not Entra-registered or compliant.
• Attempt to open a targeted app, such as Outlook on the web or the Teams desktop client.
• Expected result: access is denied with a Conditional Access policy message.
• Check Microsoft Entra Sign-in logs to confirm Entra logged the block event against the correct policy name.
• Test your break-glass account separately to confirm it still has full access.

If a user reports unexpected blocking, check their group membership, device compliance state, and whether overlapping policies exist.

Using the What If Tool

The What If tool in the Conditional Access blade lets you simulate a specific user's sign-in scenario without triggering real enforcement. Enter the user, target app, device platform, and client app type, then run the simulation. The tool returns which policies apply and what the outcome would be. Use it any time a user's access behaviour does not match your expectations.

For automating related device management tasks across your tenant, the Deploy Desktop Shortcuts with Intune Using PowerShell tutorial shows how to combine Intune and PowerShell for scalable endpoint control.