← Back to Blog

Conditional Access Policies for Microsoft Copilot: Lock It Down

E2E Agentic Bridge·March 4, 2026

Copilot Without Conditional Access Is an Open Door

You wouldn't let every employee access your ERP system from a personal phone on airport WiFi. So why are you letting them use Copilot — a tool that can access every document, email, and chat in your tenant — without any access controls?

Microsoft Entra ID Conditional Access is the policy engine that controls who can access what, from where, and under what conditions. As of late 2025, Microsoft added explicit support for targeting Copilot and generative AI services in Conditional Access policies. This means you can now apply the same Zero Trust controls to Copilot that you (hopefully) already apply to other M365 services.

Most organizations haven't done this yet. They deployed Copilot licenses and called it a day. This guide shows you how to fix that.

How Conditional Access Works with Copilot

Conditional Access policies evaluate signals — user identity, device state, location, risk level — and make access decisions based on those signals. With the Conditional Access protections for Generative AI update, you can now target specific AI services including:

  • Microsoft 365 Copilot — the productivity Copilot in Word, Excel, PowerPoint, Teams, Outlook
  • Microsoft Security Copilot — the security operations assistant
  • Microsoft Copilot — the standalone chat experience (formerly Bing Chat Enterprise)

Each of these can be targeted independently in Conditional Access policies, which means you can have different access requirements for your security team using Security Copilot versus your marketing team using M365 Copilot.

The App Registration Angle

Copilot services appear as enterprise applications in Entra ID. When you create a Conditional Access policy, you select these apps as targets:

  • Microsoft 365 Copilot appears as a selectable cloud app
  • Microsoft Security Copilot has its own app registration (app ID: b0cf1501-8e0f-4fbb-b70a-52ca5ea7bda6)
  • Copilot Studio agents can also be targeted if you've deployed custom agents

This granularity matters. A blanket policy that blocks all Copilot access from unmanaged devices might be too aggressive. But a policy that requires MFA and a compliant device specifically for M365 Copilot — while allowing Copilot Chat from any device — gives you security without killing productivity.

Five Conditional Access Policies Every Copilot Deployment Needs

Policy 1: Require Compliant Devices for M365 Copilot

This is the most important policy. M365 Copilot can access sensitive documents, emails, and chats. It should only work on devices your organization manages.

Configuration:

  • Users: All users with Copilot licenses (use a dynamic group)
  • Cloud apps: Microsoft 365 Copilot
  • Conditions: Device platforms — Windows, macOS, iOS, Android
  • Grant: Require device to be marked as compliant OR Require Hybrid Azure AD joined device
  • Session: None

Why it matters: An employee accessing Copilot from their teenager's gaming PC can inadvertently cache sensitive data on an unmanaged device. Copilot responses may include snippets of confidential documents that end up in browser history, local caches, or screenshots.

Policy 2: Block Copilot from High-Risk Locations

If your organization doesn't operate in certain countries, there's no reason Copilot should work from those locations.

Configuration:

  • Users: All users
  • Cloud apps: Microsoft 365 Copilot, Microsoft Security Copilot
  • Conditions: Locations — Include "All locations," Exclude "Trusted locations" (your office IPs, VPN ranges, named countries where you operate)
  • Grant: Block access

The VPN consideration: If you block by location, make sure your VPN exit points are in your trusted locations list. Remote workers using a corporate VPN should still have access. Remote workers on personal connections from blocked countries should not.

Policy 3: Require MFA for Copilot Access

Even from trusted devices and locations, Copilot access should require strong authentication. A stolen session token shouldn't grant access to an AI that can summarize your entire tenant.

Configuration:

  • Users: All users with Copilot licenses
  • Cloud apps: Microsoft 365 Copilot
  • Conditions: None (apply universally)
  • Grant: Require multifactor authentication
  • Session: Sign-in frequency — 4 hours (forces re-authentication)

The sign-in frequency detail: Default session lengths in M365 can extend for days. A 4-hour sign-in frequency for Copilot means that even if a session token is compromised, the window of exposure is limited. Adjust based on your risk tolerance — highly regulated environments might want 1 hour.

Policy 4: Block Copilot for High-Risk Users

Entra ID Protection assigns risk levels to users based on behavioral signals — impossible travel, leaked credentials, anomalous activity. High-risk users should lose Copilot access immediately.

Configuration:

  • Users: All users
  • Cloud apps: Microsoft 365 Copilot, Microsoft Security Copilot
  • Conditions: User risk — High
  • Grant: Block access (or require password change + MFA)

Why block rather than require MFA: If a user's credentials are confirmed compromised (high risk), MFA alone might not be sufficient — the attacker may have already registered their own MFA method. Blocking access and requiring an admin-assisted password reset is the safer path.

Policy 5: Restrict Copilot Sessions on Unmanaged Devices

Sometimes you need to allow Copilot from unmanaged devices (BYOD scenarios, contractors) but with restrictions. Conditional Access session controls let you do this.

Configuration:

  • Users: External users, BYOD group
  • Cloud apps: Microsoft 365 Copilot
  • Conditions: Device state — Unmanaged devices
  • Grant: Require MFA
  • Session: Use Conditional Access App Control (route through Defender for Cloud Apps), app-enforced restrictions

What session controls do: When routed through Defender for Cloud Apps, you can prevent downloads, block copy/paste, add watermarks to viewed content, and monitor session activity in real time. This means a contractor can use Copilot to draft a document but can't download the sensitive files Copilot references.

The Copilot-Specific Gotchas

Gotcha 1: Copilot Chat vs M365 Copilot Are Different Apps

The standalone Copilot chat (copilot.microsoft.com) and M365 Copilot (embedded in Office apps) are separate cloud apps in Entra ID. A policy targeting one doesn't automatically target the other. If you only lock down M365 Copilot, users can still access Copilot Chat and potentially get work-related responses based on their M365 data through the Graph-grounded experience.

Gotcha 2: The Conditional Access Optimization Agent

As of November 2025, Microsoft introduced the Conditional Access Optimization Agent in Security Copilot. This agent analyzes your existing policies and suggests improvements based on Zero Trust principles. It's worth running — but review every suggestion before implementing. Automated policy changes to your access controls should never be auto-approved.

Gotcha 3: Custom Security Attributes for Granular Control

For organizations needing extremely granular control, Entra ID custom security attributes can tag applications with metadata that Conditional Access policies can evaluate. This lets you create policies like "block Copilot access for users in the Finance custom attribute group when accessing from non-corporate networks" — a level of granularity that standard group-based policies can't achieve.

Gotcha 4: Copilot Plugins Inherit the Base Policy

When users install Copilot plugins (third-party or custom), those plugins operate within the Copilot session. Your Conditional Access policy for M365 Copilot applies to the base Copilot experience, but plugin-specific data flows may not be covered. If you've deployed custom agents through Copilot Studio, check that your plugin security controls are aligned with your Conditional Access policies.

Monitoring and Troubleshooting

The Sign-In Logs

After deploying Conditional Access policies for Copilot, monitor the Entra ID sign-in logs for:

  • Blocked sign-ins — are legitimate users getting locked out?
  • Conditional Access failure reasons — which policies are triggering most often?
  • Location anomalies — are you seeing sign-in attempts from unexpected locations?

Navigate to Entra ID → Monitoring & health → Sign-in logs, filter for the Copilot app registration, and review the Conditional Access tab on individual sign-in entries.

Report-Only Mode

Never deploy Conditional Access policies for Copilot in enforcement mode on day one. Use Report-only mode first:

  1. Create the policy in report-only mode
  2. Monitor sign-in logs for 1-2 weeks
  3. Identify users who would be blocked
  4. Adjust policy conditions (add exclusions, modify device requirements)
  5. Switch to enforcement mode

Skipping report-only mode is how you end up with 200 help desk tickets on a Monday morning because the CEO can't use Copilot from their iPad at their vacation home.

The Emergency Access Account Exception

Your break-glass (emergency access) accounts should be excluded from all Conditional Access policies, including Copilot policies. These accounts exist for scenarios where normal authentication is unavailable. If they're blocked by Conditional Access, they can't serve their emergency purpose.

Integration with Zero Trust

Conditional Access is one pillar of a Zero Trust deployment for Copilot. The other pillars — identity verification, device compliance, network segmentation, and data classification — all feed signals into Conditional Access decisions.

The strongest Copilot security posture combines:

  • Conditional Access (this article) — controls access based on identity, device, and context
  • Sensitivity labels — controls what data Copilot can surface
  • DLP policies — prevents Copilot from exposing sensitive information
  • SharePoint permissions — limits what content Copilot can even see

Each layer compensates for gaps in the others. Conditional Access without sensitivity labels means trusted users on compliant devices can still ask Copilot to surface data they shouldn't see. Sensitivity labels without Conditional Access means the right data protections exist but anyone from anywhere can trigger them.

Deployment Checklist

Before you go live with Conditional Access for Copilot:

  • [ ] Identify all Copilot cloud app registrations in your Entra ID tenant
  • [ ] Create dynamic groups for Copilot-licensed users
  • [ ] Define trusted locations (office IPs, VPN ranges, approved countries)
  • [ ] Deploy policies in report-only mode first
  • [ ] Monitor sign-in logs for 1-2 weeks
  • [ ] Exclude emergency access accounts
  • [ ] Document policies and share with your help desk team
  • [ ] Plan user communication — explain why MFA is required for Copilot
  • [ ] Switch to enforcement mode during a low-impact window
  • [ ] Set up alerts for policy failure spikes

The Cost of Not Doing This

A Copilot deployment without Conditional Access is a SharePoint permissions audit waiting to fail. You can have perfect permissions and perfect sensitivity labels, but if an attacker compromises credentials and there's no Conditional Access requiring device compliance or location restrictions, they get full Copilot access to your tenant.

The average cost of a data breach in 2025 was $4.88 million (IBM Cost of a Data Breach Report). Conditional Access policies take an afternoon to configure. The math isn't complicated.

Take Action Now

Want to know if your Conditional Access policies have gaps that Copilot could exploit? Run a free scan to assess your Entra ID configuration and get specific policy recommendations for your Copilot deployment.