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.
The Security Layer That 80% of Tenants Are Missing
Quick Answer: Conditional Access policies in Microsoft Entra ID control who can access M365 applications, from what devices, from which locations, and under what conditions. Most organizations have basic Conditional Access policies for email and SharePoint but have not reviewed or updated them for Copilot. Since Copilot operates through existing M365 applications, any gap in your Conditional Access coverage is also a gap in your Copilot security. The 5 essential policies: require compliant device, block unmanaged devices, require MFA, location-based restrictions, and session controls. Without these, Copilot can be accessed from unmanaged personal devices, from any country, without multi-factor authentication.
Conditional Access is the Zero Trust enforcement point for Microsoft 365. It evaluates every authentication request against a set of policies and makes a real-time decision: grant access, require additional verification, limit functionality, or block entirely. For organizations deploying Copilot, Conditional Access is the control plane that determines who can use Copilot, under what conditions, and from which devices and locations.
The problem: most organizations deployed their Conditional Access policies years ago, before Copilot existed. Those policies were designed to protect email, SharePoint, and Teams access — not to govern an AI assistant that can search, summarize, and generate content across the entire M365 tenant. The policies are technically still enforced for Copilot (since Copilot operates through M365 apps), but they were not designed for the amplified risk that Copilot introduces.
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 had to know what to look for and where to find it. With Copilot, a compromised account can query the entire tenant using natural language. The difference in data exposure speed and scope is exponential.
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 “good enough” before Copilot may be dangerously insufficient now. A policy that allows access from unmanaged devices — acceptable when the worst case was an attacker browsing files — is unacceptable when the worst case is an attacker using Copilot to extract and aggregate sensitive data across your entire tenant in 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 700+ tenants shows that 80% of organizations enabling Copilot have not updated their Conditional Access policies to account for the amplified data exposure risk. Many tenants have basic Conditional Access (MFA for admin accounts, block legacy authentication) but lack the comprehensive policies needed 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, named locations enable geographic and network-based access controls that limit where sensitive data can be accessed.
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: For organizations subject to GDPR, HIPAA, or data residency requirements, named locations are essential. Copilot queries can return data that is subject to geographic restrictions. If an employee accesses Copilot from a country where certain data categories cannot be processed, the Copilot response itself may constitute a compliance violation. Named locations prevent this by blocking Copilot access from non-approved regions entirely.
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 performs Copilot & M365 Tenant Security Reviews for enterprises across all industries. With 700+ tenants secured and 29 years of Microsoft expertise, we identify exactly what Copilot can access that it shouldn't.
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.