This post lists the ten security and governance gaps we find most often in Microsoft 365 tenants before a Copilot deployment, and explains why Microsoft’s own prerequisites will not catch any of them.
It covers what Microsoft actually requires versus what it merely recommends, the identity weaknesses that turn one compromised account into access across the estate, the data protection gaps that leave Copilot outside your existing controls, the sharing and lifecycle problems that accumulate quietly over years, and which detection tools sit behind which licensing tier.
If you are weighing up a Copilot rollout, the useful question is not whether your tenant meets the requirements. It is whether anyone has looked at the things the requirements do not check.
What Microsoft Actually Checks
There is a belief worth dealing with before the list, because it is why the list exists: if Microsoft is recommending Copilot, our environment must already be ready for it.
Microsoft’s own documentation says otherwise, and says it plainly.
The minimum requirements page splits everything into two columns. Required to deploy covers licensing, an Exchange Online mailbox, an Entra ID account, supported operating systems and browsers, and network endpoints. Strongly recommended covers SharePoint governance, Purview labeling, and phased rollout. Microsoft describes the second column as optional but strongly recommended readiness steps.
Look at what is in the required column. Does the user have a license, a cloud mailbox, an identity, a working browser, and a network path.
Every one of those answers the same question, which is whether Copilot will function. Not one of them looks at your permissions, your guest population, your admin footprint, or whether any of your data is classified.
Microsoft does tell you to do the review. Its data and compliance readiness page states that it is crucial for you to ensure that your organization’s data is protected and appropriately governed, then walks through reducing oversharing, ensuring sites have valid owners, cleaning up unused sites, and controlling access to content.
That guidance sits in the recommended column. Deployment proceeds whether or not you have followed any of it.
So the misconception is not that Microsoft has been unclear. It is that organizations read “we meet the requirements” as “we are ready,” when Microsoft has drawn the line between those two things in its own table.
Identity and Access: the First Five
Identity is where we start every assessment, because Copilot inherits whatever an identity can reach. A weak account is no longer just a weak account. It is a natural-language interface onto everything that account was ever granted.
Incomplete multifactor authentication coverage
This is the one organizations most often believe they have already solved, usually because Microsoft has been enforcing MFA and they assume that enforcement covered everyone.
It did not. Microsoft’s mandatory MFA applies to administrative sign-ins, rolled out in phases: the Azure and Entra admin portals from October 2024, the Microsoft 365 admin center from February 2025, and Azure Resource Manager clients including command line, PowerShell, and the mobile app from October 2025. Those dates have passed. End users were never in scope.
Gaps show up where tenants still run per-user legacy MFA, or exclude groups from Conditional Access, or never moved off the defaults. Microsoft’s own research puts the value of closing it plainly, stating that MFA can block more than 99.2 percent of account compromise attacks.
Standing privileged access and stale admin accounts
Permanent role assignments that stay live around the clock, plus admin accounts nobody has used in a year and nobody has removed.
Just-in-time elevation, time-bound roles, approval workflows, and recurring reviews of privileged roles are all available, but they require Entra ID P2 or Entra ID Governance. Tenants without that licensing can see their role assignments but cannot automate anything about them.
Excessive or stale guest access
External collaboration is on by default, and by default users can invite guests, including existing guests inviting more. Cross-tenant defaults leave external organizations enabled for collaboration.
None of that is wrong. The problem is that nobody owns the guest lifecycle once a project ends, so guests accumulate for years. Recurring access reviews that recertify and automatically remove non-responders need Entra ID P2 or Governance.
Legacy authentication still permitted
Older protocols cannot enforce MFA, which makes them the standing bypass around everything in item one. Microsoft states that more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication, and that both would stop with it blocked.
The long tail is usually a handful of line-of-business applications and devices still authenticating the old way. Blocking through Conditional Access requires Entra ID P1.
Conditional Access exclusions that became permanent
Excluding a break-glass account from Conditional Access is correct practice and Microsoft recommends it. The problem is everything else that gets excluded alongside it: service accounts, an integration that broke once, a group added during testing.
Policies that never moved out of report-only are the other half of this. They look like coverage in the admin center and enforce nothing.
A weak identity is now a natural-language interface onto everything it can reach.
We can check MFA coverage, standing privileged access, and stale guest accounts against your actual tenant, not just against the defaults.
Data Protection: the Next Three
Sensitivity label coverage
Copilot honors sensitivity labels and displays the most restrictive label of any content it draws on. That only works where content is labeled, and in most estates label penetration is low.
This is the quiet dependency underneath item seven. Label-based controls protect labeled content. Everything unclassified is invisible to the exact protections meant to contain Copilot.
Data loss prevention that does not cover Copilot
This one surprises people, and it is worth stating carefully.
Purview DLP now has a dedicated policy location for Microsoft 365 Copilot and Copilot Chat. A policy scoped there can stop Copilot processing labeled files in its responses, with the item still appearing as a citation while its content goes unused.
Existing DLP policies scoped to Exchange, SharePoint, and endpoints do not automatically extend to Copilot prompt processing. So an organization can have DLP, believe it is covered, and have Copilot interactions sitting entirely outside it.
Audit retention that expires before you need it
Copilot prompts and responses are captured in the unified audit log, including which service the activity occurred in and references to files accessed. That part works out of the box.
The retention is the catch. Standard auditing keeps records for 180 days. Premium auditing extends Entra, Exchange, OneDrive, and SharePoint records to a year, but other workloads including Copilot stay at 180 days unless you write a custom retention policy to extend them.
Sharing and Lifecycle: the Last Two
Outdated external sharing policies
Tenant and site sharing settings govern anonymous links, guest links, and company-wide links. Anonymous links can be forced to expire. Company-wide links historically could not, which is why long-lived tenants carry years of them.
A company-wide link is redeemable by any authenticated user who obtains it, not only the person it was sent to, and Copilot honors that access once redeemed. Microsoft has been rolling out expiration for these links, so check whether it has reached your tenant.
Agent governance nobody has decided on
Agents extend Copilot into connectors and data sources, and unlike Copilot itself they can act rather than only retrieve.
Controls exist. Tenant-level agent controls sit in the Microsoft 365 admin center, Copilot Studio governance sits in the Power Platform admin center, and Microsoft describes a zoned model separating citizen, partnered, and professional development.
The gap is not tooling. It is that most organizations have never made the decision the tooling implements: who is allowed to build agents, what those agents can reach, and what they are allowed to do rather than just read.
On SharePoint Oversharing
It belongs on this list and it is the largest item of all, which is why it has its own post rather than a paragraph here. The short version: Copilot honors existing permissions and creates no new access, so what surfaces was already exposed.
Why This Matters More Once Copilot Is On
Worth being precise here, because the overstated version of this argument is easy to dismiss.
Copilot does not break, escalate, or expand permissions. It creates no new access. Every one of the ten issues above was already a problem yesterday, and a determined attacker could already have exploited most of them.
What changes is friction, and friction was doing more work than anyone acknowledged.
Before Copilot, exploiting a stale guest account or a compromised login meant knowing which site to look in, which folder, and roughly what the file was called. Most exposure survived on nobody bothering. Microsoft’s own documentation states that because of the power and speed of AI it can proactively surface content that might be obsolete, over-permissioned, or lacking governance controls, and that generative AI amplifies the problem of oversharing data.
So the accurate framing for a decision-maker is not that Copilot is dangerous. It is that Copilot is the first tool that will actually exercise a decade of accumulated misconfiguration, at speed, on behalf of whoever holds the account.
That reframes the spending decision too. This is governance debt coming due, not an AI safety project. The work was always needed. Copilot just set a date on it.
What You Can Check Yourself, and What You Cannot
Most of the detection above exists natively. The catch is that seeing a problem and being able to do something about it sit at different licensing tiers, and the hardest parts are not licensing problems at all.
The pattern across the right column is worth naming. Two of these are money, several are time, and the rest are judgment. The judgment ones cannot be bought or automated, and they are consistently the ones that stall a readiness project.
Where to Start
Do the identity work before a single license is assigned. Check MFA registration across all users rather than admins, inventory your privileged roles and remove standing access you cannot justify, and run one guest review. None of that needs Copilot to be bought first, and all of it is worth doing regardless.
Do the data protection work during a pilot, not after. Tighten sharing, measure label coverage on your most sensitive content, put a DLP policy on the Copilot location, and extend audit retention to match whatever your compliance horizon actually is.
Decide the agent question before you scale, because it is the only item on this list that gets harder the longer you wait. Once people are building agents, restricting who can build them becomes a political conversation rather than a technical one.
Two sequencing warnings from experience. Never enforce Conditional Access or block legacy authentication before mapping which service accounts and applications depend on them, because that is the classic self-inflicted outage. And assign a named owner to every finding before you run any assessment, because the alternative is a report that ages while the exposure stays exactly where it was.
WME runs Copilot readiness assessments across identity, data protection, and permissions, with findings sequenced into what to fix now, what needs a licensing decision, and what needs a business owner.
Ten issues, sequenced into what to fix now, what needs a licensing decision, and what needs a business owner.
WME runs Copilot readiness assessments across identity, data protection, and permissions.
