Mitigating Microsoft 365 Copilot access risk: Identity and device controls for Zero Trust

In our previous post, we mapped where exposure can exist when organizations deploy Microsoft 365 Copilot and grouped those risks into two layers. Layer 1 focused on who can access Copilot—the identity and device conditions that determine whether a user can reach the service.  

If those identity and device conditions are weak, exposure may extend beyond a single workload across the user’s entire Microsoft 365 data surface. This post shifts from mapping risk to reducing it. 

Each of the six Layer 1 risks (R1–R6) is governed primarily by the identity and endpoints pillars of Zero Trust. The good news: customers with Microsoft 365 E5 already own the controls required to address these risks, including Microsoft Entra ID, Conditional Access, Microsoft Intune, and Microsoft Defender. The next job is configuring and scoping them deliberately before scaling deployment.

How to read this post 

Each section recaps one risk, describes the mitigation, names the Microsoft control that delivers it and indicates where to capture the supporting screenshot. These controls are additive. Conditional Access ties identity and device signals together, so several mitigations reinforce one another. 

R1—Unmanaged identity access 

Pillar: Identity 

Because Copilot operates across the full scope of a user's permissions, a compromised, shared, or orphaned account exposes far more than it would have before. Mitigation starts with disciplined identity lifecycle management so that accounts exist only when they should and belong to real users. 

What to do: 

• Automate joiner, mover, and leaver processes with Microsoft Entra Lifecycle Workflows so accounts are provisioned, re-scoped, and disabled on schedule rather than manually. 
• Run recurring access reviews on Copilot-licensed groups to identify stale or unnecessary accounts.
• Eliminate shared and generic accounts; require an individual, attributable identity for every Copilot user.
• Block or remove dormant accounts and monitor sign-in activity for privileged identities. 

The following examples show lifecycle workflows and access review configuration: 

Figure: Lifecycle Workflows—leaver workflow showing account-disable tasks

 

Figure: Access reviews—review scoped to the Copilot users group

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

R2—Weak or absent multi-factor authentication 

Pillar: Identity 

If MFA is inconsistent—or legacy authentication bypasses modern sign-in controls—an attacker may need only a stolen password to open a Copilot session that synthesizes data across services. Closing this gap means enforcing strong authentication consistently and shutting down the protocols that route around it. 

What to do: 

• Require MFA for all users with a Conditional Access policy; use Microsoft-managed policies as a baseline, then tighten. 
• Move to phishing-resistant authentication methods, such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication.
• Block legacy authentication protocols that don't support modern MFA.
• Turn on Microsoft Authenticator number matching and additional context to help resist MFA fatigue attacks. 

Figure: Conditional Access—require multifactor authentication policy

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Authentication methods—phishing-resistant methods enabled

 

 

 

 

 

 

 

 

 

 

 

 

 

R3—Unmanaged or noncompliant devices 

Pillar: Endpoints 

Users can reach Copilot from any device where they can authenticate. Without endpoint protection, encryption, and compliance evaluation, sessions and their outputs can be stored or exfiltrated from untrusted devices. Mitigation pairs device compliance in Intune with a Conditional Access policy that enforces it. 

What to do: 

• Define Intune compliance policies that require disk encryption, minimum OS versions, endpoint protection (EDR/Defender), and no jailbreak or root status. 
• Use a Conditional Access grant control that requires devices to be marked compliant, or hybrid Microsoft Entra joined before accessing Microsoft 365 and Copilot.
• Feed Microsoft Defender for Endpoint device risk signals into compliance evaluation, so high-risk devices fall out of compliance automatically. 

Figure: Intune compliance policy—encryption, minimum OS, and Defender requirements

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Conditional Access—require device to be marked as compliant

 

 

 

 

 

 

 

 

 

 

 

 

 

R4—License sprawl without role-based scoping 

Pillar: Identity and apps 

Broad pilot enrollment—licensing whole departments or floors—is itself a risk factor because it grants Copilot access to both well-governed and minimally governed users without an access review. Mitigation makes licensing deliberate: a reviewed group assigned through policy after each member's access is checked. 

What to do:

• Assign Copilot through group-based licensing tied to a named, security-reviewed pilot group—not by department or location. 
• Run an access review on each pilot member's permission posture and role sensitivity before granting the license.
• Phase rollout in cohorts and consider Restricted Content Discovery during the pilot to limit the grounding surface. 

Figure: Microsoft 365 admin center—Copilot license assignment count

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

R5—Missing real-time risk evaluation at sign-in 

Pillar: Identity and endpoints 

Static controls grant or deny access once; they don't react to a session that turns risky. If Conditional Access doesn’t evaluate sign-in and user risk signals—impossible travel, anomalous tokens, Identity Protection alerts—a high-risk session can still reach Copilot before anyone responds. Mitigation makes access decisions risk-aware in real time. 

What to do:

• Turn on Microsoft Entra ID Protection (included in E5) to generate user risk and sign-in-risk signals. 
• Create risk-based Conditional Access policies: require MFA or a secure password change on elevated risk, and block on high risk.
• Add token protection to bind sign-in sessions to the device and reduce token replay exposure. 

Figure: Conditional Access—user risk condition set

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Identity Protection—risky sign-ins dashboard

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Conditional Access—require token protection session control

 

 

 

 

 

 

 

 

 

 

 

 

 

R6—App protection gap on mobile devices 

Pillar: Endpoints and apps 

On personal phones that aren't enrolled in MDM, organizations still need to govern the app. Without an application protection policy, users can copy Copilot output into unmanaged apps, and data on a lost device can't be wiped. Mobile Application Management (MAM) protects corporate data inside the app without managing the whole device. 

What to do:

• Deploy Intune App Protection Policies (MAM) for iOS and Android: require an app PIN, encrypt app data, and allow selective wipe of organizational data. 
• Restrict data egress: block copy/paste and 'Save As' to unmanaged locations, and block screen capture where the platform supports it (Android).
• Pair with a Conditional Access grant requiring an approved client app and an app protection policy for mobile access. 

Figure: Intune app protection policies—iOS and Android policy list

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: App protection policy—data protection, block copy/paste, and “Save As”

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Conditional Access—require approved client app and require App Protection Policy

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Layer 1 mitigations at a glance 

Each Layer 1 risk maps to a primary control and the Microsoft tool that delivers it. Conditional Access recurs because it is where identity and device signals are enforced together. 

Securing Copilot access isn't only about who can sign in—it's about validating the devices, conditions, and access patterns behind every session. The six controls above close Layer 1 gaps before risky access patterns scale across the organization. 

Governing Microsoft 365 Copilot risk: Next steps 

Microsoft 365 Copilot security starts before a prompt is ever entered. Identity, device, and session controls help verify that the right people are accessing Copilot from trusted devices under the right conditions. Closing Layer 1 gaps reduces the likelihood that compromised identities, risky sign-ins, or unmanaged devices can access organizational data. 

Controlling who can access Copilot is the first step. The next challenge is governing what Copilot can access once a user is authenticated. Strong access controls reduce the chances that the wrong person reaches Copilot. Layer 2 focuses on a different question: if the right person signs in, what information can they discover, summarize, and use? 

In the next post of this series, we'll shift from access controls to data controls and explore how organizations can reduce Layer 2 risk through SharePoint and OneDrive permissions management, sensitivity labels, data loss prevention (DLP), connector governance, and auditing capabilities. 

Before expanding your Copilot deployment, review the six Layer 1 controls covered in this article and identify any gaps in your identity, device, and access policies. You can also use the Zero Trust Workshop to assess your current security posture and prioritize remediation efforts. 

When you're ready, continue to Post 3 in this series: Governing Microsoft 365 Copilot data risk to examine how data governance controls help limit exposure after authentication and strengthen secure Copilot adoption. 

Atil Gurcan is a Senior FastTrack Architect who works with customers to implement secure & compliant AI experiences and accelerate their digital transformation, increasing ROI for their investments with Microsoft.