Conditional Access for Copilot: The Missing Security Layer in Most M365 Tenants
Copilot can access your entire M365 tenant from any device, any location, without MFA. Unless you configure Conditional Access to say otherwise.
Most Microsoft 365 tenants have zero Conditional Access policies governing Copilot. Without them, Copilot can access your entire tenant from any device, any location, with no MFA required. Every enterprise deploying Copilot needs five core policies: compliant device required, unmanaged device blocked, MFA enforced, location-based restrictions, and session controls.
Key Facts
- 80% of M365 tenants have no Conditional Access policies targeting Copilot access.
- Copilot accesses all content the user can reach — including sensitive data — within seconds via natural language prompts.
- A manual attacker takes hours to find sensitive files; Copilot takes seconds with a simple prompt like "Show me salary data."
- Five policies close the most critical gaps: compliant device, block unmanaged, MFA, location-based, and session controls.
- All policies should be deployed in Report-Only mode first. Monitor for 7–14 days before enforcement.
The Security Layer That 80% of Tenants Are Missing
Quick Answer: Conditional Access policies in Microsoft Entra ID control access to M365 applications. These policies define who can access the applications, which devices are allowed, and the required conditions.
Many organizations create basic policies for email and SharePoint. However, they frequently neglect to update policies for Copilot.
Since Copilot uses existing M365 applications, any gaps in your Conditional Access policies also affect Copilot security. Here are the 5 essential policies to implement:
- Require compliant devices
- Block unmanaged devices
- Require multi-factor authentication (MFA)
- Implement location-based restrictions
- Set session controls
Without these policies, Copilot can be accessed from unmanaged personal devices, from any country, and without multi-factor authentication.
Conditional Access is the Zero Trust enforcement point for Microsoft 365. It assesses each authentication request based on set policies. This assessment results in a real-time decision to:
- Allow access to resources
- Deny access based on risk factors
- Require additional verification steps
- Grant access
- Require additional verification
- Limit functionality
- Block access completely
For organizations using Copilot, Conditional Access acts as the control plane. It defines:
- Who can use Copilot
- The conditions under which Copilot can be used
- The devices and locations from which Copilot can be accessed
Many organizations set up their Conditional Access policies years ago, before Copilot was introduced. These policies aimed to secure access to:
- SharePoint
- Teams
However, they do not account for an AI assistant that can search, summarize, and generate content across the entire M365 tenant.
While the policies still apply to Copilot, as it operates through M365 apps, they were not created to address the increased risks that Copilot brings.
EPC Group's 47-Point Copilot & M365 Security Review evaluates Conditional Access policies specifically through the lens of Copilot security — identifying gaps that were acceptable before Copilot but are unacceptable now.
Why Conditional Access Matters More for Copilot
Before Copilot, a compromised account could access individual files, emails, and Teams messages. The attacker needed to know what to look for and where to find it.
With Copilot, a compromised account can now query the entire tenant using natural language. This change greatly increases the speed and scope of data exposure.
Before Copilot (Manual Search)
- Hours to find specific sensitive data
- Requires knowledge of file locations
- Limited by search skill of attacker
- Data extraction is file-by-file
- Cross-source correlation requires manual effort
With Copilot (AI-Assisted Search)
- Seconds to find sensitive data via natural language
- No knowledge of file structure needed
- Simple prompts: “Show me salary data”
- Data extracted and summarized automatically
- Cross-source aggregation is automatic
The Implication: Conditional Access policies that were once "good enough" may now be dangerously inadequate. A policy that allows access from unmanaged devices was acceptable when the worst-case scenario involved an attacker simply browsing files. However, this is no longer sufficient. Now, the worst-case scenario could involve an attacker using Copilot to extract and compile sensitive data from your entire tenant in just minutes.
Default Copilot Access: No Restrictions
Out of the box, Microsoft 365 Copilot inherits whatever Conditional Access policies exist for the M365 applications it operates through. For many organizations, this means minimal or no restrictions.
What “Default” Looks Like in Most Tenants
- No device compliance requirement — Copilot works on any device, managed or unmanaged
- No MFA for M365 apps — password-only authentication gives full Copilot access
- No location restrictions — Copilot accessible from any country, any network
- No session controls — sessions persist indefinitely, no re-authentication required
- No application-specific policies — all M365 apps treated identically regardless of Copilot risk
- No monitoring — no alerts when Copilot is accessed from unusual locations or devices
EPC Group's audit data from over 700 tenants reveals that 80% of organizations using Copilot have not updated their Conditional Access policies. This oversight increases the risk of data exposure.
Many tenants have basic Conditional Access measures, including:
- Multi-Factor Authentication (MFA) for admin accounts
- Blocking legacy authentication
However, they often lack the comprehensive policies necessary for an AI assistant that can search the entire tenant.
5 Conditional Access Policies Every Tenant Needs for Copilot
Require Compliant Device
CriticalCopilot should only be accessible from devices that meet your organization's compliance standards — enrolled in Intune, with endpoint protection active, disk encryption enabled, and OS patches current.
Conditions
All users, all M365 cloud apps
Grant Control
Require device to be marked as compliant
Impact
Blocks Copilot access from personal devices, unmanaged workstations, and devices that fail compliance checks. Users on non-compliant devices cannot query Copilot until their device is remediated.
Block Unmanaged Devices
CriticalExplicitly block access to M365 applications (and therefore Copilot) from devices not enrolled in Intune or a supported MDM solution. This is the backstop for Policy 1 — it catches devices that are not even attempting compliance.
Conditions
All users, all M365 cloud apps, device filter: unmanaged
Grant Control
Block access
Impact
Users cannot access Copilot-enabled applications from any unmanaged device. This prevents data exposure on personal laptops, shared computers, and public terminals. Exceptions should be documented for break-glass accounts only.
Require Multi-Factor Authentication
CriticalAll access to M365 applications must require MFA. A compromised password without MFA gives an attacker full Copilot access — the ability to search your entire tenant for sensitive information using natural language queries.
Conditions
All users, all M365 cloud apps, any location
Grant Control
Require multifactor authentication
Impact
Every Copilot session requires MFA verification. Reduces the risk of credential-based attacks leading to Copilot data extraction. Use phishing-resistant MFA methods (FIDO2 security keys, Windows Hello for Business) for maximum protection.
Location-Based Restrictions
HighRestrict M365 application access by network location. Allow full access from corporate networks, require additional verification from non-corporate networks, and block access from countries where the organization does not operate.
Conditions
All users, all M365 cloud apps, named locations (trusted/untrusted)
Grant Control
Require MFA from non-trusted locations, block from prohibited locations
Impact
Copilot access from non-corporate networks requires additional authentication. Access from countries without business operations is blocked entirely. Reduces risk from stolen credentials used in foreign locations.
Session Controls
HighEnforce session lifetime limits and persistent browser restrictions. Copilot sessions should require re-authentication periodically and should not persist across browser closures on non-corporate devices.
Conditions
All users, all M365 cloud apps, non-compliant devices
Grant Control
Sign-in frequency: 8 hours, persistent browser session: disabled
Impact
Limits the window of exposure if a session is compromised. Prevents abandoned sessions from being used by unauthorized parties. Forces re-authentication on shared or non-corporate devices.
Named Locations for Copilot Access Control
Named locations define trusted and untrusted network ranges for Conditional Access policies. For Copilot, these locations enable geographic and network-based access controls. This helps restrict access to sensitive data.
Trusted Locations
- Corporate office IP ranges
- VPN endpoint addresses
- Branch office networks
- Managed corporate Wi-Fi networks
- Cloud proxy egress IPs (Zscaler, Netskope)
Block or Restrict
- Countries without business operations
- Known Tor exit nodes and anonymizer services
- Public Wi-Fi networks (airports, hotels, cafes)
- Residential ISP ranges (unless VPN is active)
- IP ranges associated with known threat actors
Data Sovereignty Note: Organizations that must comply with GDPR, HIPAA, or data residency rules should use named locations. Copilot queries may return data that has geographic restrictions.
If an employee uses Copilot in a country where certain data categories cannot be processed, it may result in a compliance violation.
Named locations help prevent this issue by:
- Blocking Copilot access from non-approved regions.
Testing Before Enforcement
Conditional Access policies can disrupt productivity if misconfigured. Always test in Report-only mode before enforcing. The testing process should take 7-14 days minimum.
Create in Report-Only Mode
Configure all 5 policies in Report-only mode. This logs what would happen without actually blocking or granting access. Users are unaffected during testing.
Monitor for 7-14 Days
Review the Conditional Access insights workbook in the Entra ID portal. Identify which users would be blocked, which would require MFA, and which would pass all policies.
Identify Exceptions
Find service accounts, shared mailboxes, conference room accounts, and break-glass admin accounts that may be affected. Create targeted exclusions for legitimate non-interactive accounts.
Validate Device Compliance
Ensure all corporate devices meet compliance requirements before enforcing device-based policies. Run an Intune compliance report to identify non-compliant devices that need remediation.
Enforce in Phases
Enable MFA policy first (lowest disruption risk). Then device compliance. Then location restrictions. Then session controls. Space enforcement 1 week apart to isolate issues.
Monitor Post-Enforcement
After enforcement, monitor sign-in logs for unexpected failures. Set up alerts for high volumes of Conditional Access blocks. Maintain a rapid response process for users locked out by policy.
Monitoring Copilot Access
Conditional Access policies are only effective if they are monitored. Post-deployment monitoring ensures policies are working as intended and identifies emerging risks.
Blocked Sign-Ins
Track Conditional Access blocks by policy, user, and location. Spikes indicate either attack attempts or policy misconfigurations.
MFA Success Rate
Monitor MFA completion rates. Low rates may indicate user friction or device issues. Target: 95%+ MFA success rate.
Non-Compliant Access
Track access attempts from non-compliant devices. Identify users who need device remediation or Intune enrollment.
Unusual Locations
Monitor access from locations outside normal patterns. Configure alerts for Copilot access from new countries or IP ranges.
Session Duration
Track average session lengths. Unusually long sessions may indicate compromised accounts. Compare against session control limits.
Policy Exceptions
Audit all Conditional Access exclusions quarterly. Temporary exceptions often become permanent without review.
Frequently Asked Questions
How do you configure Conditional Access for Microsoft Copilot?
Conditional Access for Microsoft Copilot is configured through Microsoft Entra ID (formerly Azure AD) Conditional Access policies. Copilot does not have a separate Conditional Access target — it operates through existing Microsoft 365 applications (Word, Excel, PowerPoint, Outlook, Teams). To control Copilot access, you configure Conditional Access policies targeting these applications with conditions such as device compliance, location, user risk level, and sign-in risk. The key policies are: require compliant device for all M365 app access (which includes Copilot), block access from unmanaged devices, require MFA for all Copilot-capable applications, restrict access by named location, and enforce session controls that limit Copilot functionality on non-corporate networks.
Does Copilot have its own Conditional Access policy target?
No. As of 2026, Microsoft Copilot does not have a dedicated Conditional Access application target. Copilot operates as a feature within existing Microsoft 365 applications — it is embedded in Word, Excel, PowerPoint, Outlook, Teams, and the Microsoft 365 app. This means Copilot inherits the Conditional Access policies applied to these applications. If you have a Conditional Access policy requiring MFA for Teams access, that policy also governs Copilot in Teams. If you have no Conditional Access policies on SharePoint Online, Copilot can access SharePoint content without additional controls. The implication: organizations must ensure their existing M365 Conditional Access policies are comprehensive, because any gap in application coverage is also a gap in Copilot coverage.
What happens if Copilot is accessed from an unmanaged device?
Without Conditional Access policies blocking unmanaged device access, Copilot can be used from any device — personal laptops, shared computers, public terminals, or smartphones without MDM enrollment. This means a user could access Copilot from a personal device with no endpoint protection, no disk encryption, and no data loss prevention controls. Copilot would return the same results as on a managed corporate device: sensitive documents, emails, meeting transcripts, and cross-source summaries. The data is then on an unmanaged device with no organizational control over retention, sharing, or security. Block unmanaged device access through Conditional Access by requiring device compliance (Intune enrollment + compliance policy) as a grant control for all M365 applications.
Should I require MFA for Copilot access?
Yes. MFA should be required for all Microsoft 365 application access, which includes Copilot. Without MFA, a compromised password gives an attacker full Copilot access — the ability to query your entire M365 tenant for sensitive data using natural language. An attacker with Copilot access could extract financial data, HR records, legal documents, strategic plans, and meeting transcripts in minutes. MFA reduces this risk by requiring a second factor (authenticator app, FIDO2 key, phone verification) that the attacker is unlikely to have. Configure Conditional Access to require MFA for all users accessing any M365 application, with no exceptions for Copilot-enabled applications.
How do named locations work with Copilot Conditional Access?
Named locations in Conditional Access define trusted network ranges (office IP addresses, VPN endpoints, corporate network ranges) and untrusted locations (specific countries, known malicious IP ranges). For Copilot, named location policies can restrict access by geographic region or network: allow full Copilot access from corporate networks, require additional MFA from non-corporate networks, block Copilot access from specific countries where the organization does not operate, and enforce session controls (time-limited sessions, no persistent browser sessions) from untrusted locations. Named locations are particularly important for organizations with compliance requirements that restrict where data can be accessed — HIPAA, GDPR, and data sovereignty regulations may require that certain data never leaves specific geographic boundaries.
What session controls should I configure for Copilot?
Session controls in Conditional Access govern the behavior of authenticated sessions. For Copilot, configure: sign-in frequency to require re-authentication every 8-12 hours (prevents long-lived sessions that could be hijacked), persistent browser session disabled for non-corporate devices (forces re-authentication when the browser is closed), Conditional Access App Control integration with Microsoft Defender for Cloud Apps to monitor Copilot usage in real-time, and application-enforced restrictions for SharePoint and OneDrive that limit what Copilot can do on non-compliant devices (view-only access, no download, no copy-paste). Session controls ensure that even authenticated users operate within defined security boundaries.
How do I test Conditional Access policies for Copilot before enforcement?
Conditional Access policies support a "Report-only" mode that logs what would happen if the policy were enforced without actually blocking or granting access. Use this approach: 1) Create the policy in Report-only mode. 2) Monitor the Conditional Access insights and reporting workbook in the Entra ID portal for 7-14 days. 3) Review which users would be blocked, which would require MFA, and which would pass. 4) Identify any unexpected impacts (service accounts, shared devices, break-glass accounts). 5) Adjust policy conditions to address exceptions. 6) Move the policy to "On" (enforced) after validating. Never skip Report-only testing — a misconfigured Conditional Access policy can lock out entire departments or break automated workflows that depend on M365 application access.
Add the Missing Security Layer to Your Copilot Deployment
EPC Group offers Copilot and M365 Tenant Security Reviews for businesses across all industries. We have secured over 700 tenants and have 29 years of experience with Microsoft. Our aim is to identify what Copilot can access that it should not.
Our 47-Point Assessment includes a full Conditional Access audit — evaluating existing policies against Copilot-specific requirements and delivering the 5 essential policies configured for your environment.
Conditional Access for Copilot: The Missing Security Layer
Most Microsoft 365 tenants lack Conditional Access policies for Copilot. This means Copilot can access your entire tenant from any device and location, without requiring MFA.
Every enterprise using Copilot should implement these five core policies:
- Compliant device required
- Unmanaged device blocked
- MFA enforced
- Location-based restrictions
- Session controls
Key facts
- 80% of M365 tenants have no Conditional Access policies targeting Copilot access.
- Copilot accesses all content the user can reach — including sensitive data — within seconds via natural language prompts.
- A manual attacker takes hours to find sensitive files; Copilot takes seconds with a simple prompt like "Show me salary data."
- Five policies close the most critical gaps: compliant device, block unmanaged, MFA, location-based, and session controls.
- All policies should be deployed in Report-Only mode first. Monitor for 7–14 days before enforcement.
Why Copilot Changes the Access Risk Equation
| Scenario | Manual Search | With Copilot |
|---|---|---|
| Time to find sensitive data | Hours | Seconds |
| Knowledge of file locations required | Yes | No |
| Cross-source aggregation | Manual, slow | Automatic |
| Example prompt needed | N/A | "Show me salary data" |
| Data extraction method | File-by-file | Summarized automatically |
A Conditional Access policy that was acceptable before Copilot is now insufficient. Allowing unmanaged device access poses serious risks. The potential for attackers has grown significantly. They can now move from browsing individual files to gathering your entire tenant in just minutes.
The Default Copilot Access Problem
By default, Microsoft 365 applies your existing Conditional Access policies to Copilot. Most tenants have broad policies with gaps.
- No policy targets Copilot-licensed users specifically.
- Unmanaged personal devices can access Copilot if any sign-in succeeds.
- No session time limits — a hijacked session persists indefinitely.
- No location restrictions — Copilot is accessible from any country.
- Guest and shared accounts can trigger Copilot queries against production data.
5 Conditional Access Policies Every Tenant Needs for Copilot
Policy 1: Require Compliant Device
Target: All users with Copilot licenses. Grant access only if the device is marked compliant by Microsoft Intune. Blocks personal and unmanaged corporate devices from running Copilot queries.
Policy 2: Block Unmanaged Devices
To enhance security, implement a second policy that blocks all devices not enrolled in Intune. This policy should run alongside Policy 1. It will help address cases where compliance status has not been evaluated yet.
Policy 3: Require Multi-Factor Authentication
Require MFA for all users licensed with Copilot during every sign-in. Avoid using outdated per-user MFA settings. Instead, implement Conditional Access MFA. This approach ensures the policy applies consistently across all devices and locations.
Policy 4: Location-Based Restrictions
Configure named locations for trusted corporate networks. Then set Copilot policies by location:
- Full Copilot access from corporate networks.
- Additional MFA step required from non-corporate networks.
- Block Copilot entirely from countries where your organization does not operate.
Policy 5: Session Controls
Limit the damage from hijacked sessions with time and persistence controls:
- Sign-in frequency: require re-authentication every 8–12 hours.
- Persistent browser session: disabled for non-corporate devices.
- Integrate Conditional Access App Control with Defender for Cloud Apps to monitor Copilot usage in real time.
- Apply application-enforced restrictions via SharePoint and OneDrive to limit actions on non-compliant devices (view-only, no download, no copy-paste).
Testing Before Enforcement
Never deploy Conditional Access policies directly to enforcement. Use this six-step process.
- Step 1: Create in Report-Only mode — policies log what would have been blocked without actually blocking.
- Step 2: Monitor for 7–14 days — review sign-in logs in Entra ID for would-be blocks.
- Step 3: Identify exceptions — flag service accounts, shared devices, and edge users who need policy exclusions.
- Step 4: Validate device compliance — check Intune enrollment rates; enroll stragglers before enforcement.
- Step 5: Enforce in phases — start with IT staff, then executives, then all Copilot-licensed users.
- Step 6: Monitor post-enforcement — watch for blocked sign-ins and adjust exclusions as needed.
Monitoring Copilot Access After Enforcement
Track these six signals in Entra ID sign-in logs and Microsoft Sentinel:
- Blocked sign-ins targeting Copilot workloads
- MFA success vs challenge rate by user group
- Non-compliant device access attempts
- Unusual location sign-ins (unexpected countries or regions)
- Session duration — unusually long sessions suggest token theft
- Policy exception usage — exceptions accumulating signal policy gaps
Frequently Asked Questions
How do you configure Conditional Access for Microsoft Copilot?
In Entra ID, you can create a Conditional Access policy. Select Microsoft 365 Copilot as the cloud app target. Then, assign the following conditions:
- Compliant device
- MFA
- Location
Deploy the policy in Report-Only mode first. Enforce it after reviewing logs for 7–14 days.
Does Copilot have its own Conditional Access policy target?
Yes, Microsoft 365 Copilot is a cloud app that can be targeted in Conditional Access. You can also target the entire Office 365 suite. Additionally, you can limit policies to users with Copilot licenses by using group membership.
What happens if Copilot is accessed from an unmanaged device?
Without a block policy, Copilot operates as usual. It can access any content that the user is allowed to view. This allows an attacker with a compromised personal device to easily gather sensitive data using Copilot.
Should I require MFA for Copilot access?
Yes, you should require MFA through Conditional Access for all users licensed for Copilot. Per-user MFA settings are insufficient. They do not function reliably across all sign-in paths.
Using Conditional Access MFA is the best way to enforce security. This method ensures that MFA is applied uniformly for all users.
How do I test Conditional Access policies for Copilot before enforcement?
Use Report-Only mode in Entra ID. This feature logs all potential blocks without actually preventing users from accessing resources.
Monitor the logs for 7–14 days. After reviewing and resolving any exceptions, you can switch to enforcement mode.
Add the Missing Security Layer to Your Copilot Deployment
EPC Group has secured 700+ Microsoft 365 tenants for Copilot deployment. Call (888) 381-9725 or schedule a Copilot Security Review.