Most Microsoft 365 tenants aren’t prepared for Copilot on day one, and the problem is seldom one of licensing; it’s usually a matter of governance. Since Copilot retrieves and summarizes all the information that a logged-in user is already permitted to see throughout Microsoft Graph, any gap in identity access, any file that hasn’t been labeled, and any outdated device now become items that Copilot can display more quickly and to a broader group of people than it could before. Therefore, before you enable Copilot, you must determine whether your identity, data, and endpoint controls are capable of withstanding that level of scrutiny.
TrustedTech divides Copilot readiness into five key areas: identity security, threat protection, data governance, endpoint management, and collaboration controls. This is based on what TrustedTech’s engineers have repeatedly observed in their Microsoft 365 Copilot Readiness Assessments, including a recent one conducted with a global commodities services provider that used a combination of Microsoft 365 E3 and E5 editions across about 250 licensed users. This assessment serves as a useful example throughout the article since, although strong Microsoft licensing and basic tools were already available, the security and governance controls had never been fully set up to production standards. For anyone who is an IT manager, a Microsoft administrator, or a CIO considering a Copilot rollout, this is the checklist to follow first.
The 5 Pillars of Copilot Readiness
Copilot enhances all those aspects that are already true regarding your tenant. In a well-governed environment, safety and speed improve with Copilot, while in a loosely governed environment, the risks become more apparent. In practice, these risks focus on five areas:
- Identity security (Entra) – who can authenticate, and under what conditions
- Threat protection (Defender) – how quickly a compromised account or device gets detected
- Data governance (Purview) – whether sensitive data is labeled, protected, and retained on a defined lifecycle
- Endpoint management (Intune) – whether exclusively compliant, managed devices can reach tenant data
- Collaboration controls (Teams, SharePoint, Exchange) – how tightly sharing and access are governed across the platforms Copilot actually reads from
The pillars below examine the common gaps that TrustedTech identifies in assessments, explain why these gaps are important specifically for Copilot (not just for security in general), and outline how to address them.
Pillar 1: Identity Security (Entra)
Copilot takes over its access model completely from Entra ID. Even if a user’s account has been compromised and Conditional Access is not closely restricted, Copilot doesn’t cause that vulnerability, but it does make it much easier to exploit since an attacker no longer has to search through folders. They can pose a natural-language question and obtain a synthesized answer drawn from all the content that the account has access to.
The most frequent gaps identified by TrustedTech’s assessments in this area are that multi-factor authentication is enforced inconsistently rather than universally, that outdated authentication methods remain enabled, that Conditional Access policies have become complex and contradictory over time, and that identity attributes (such as department, title, and manager) are incomplete, thereby disrupting downstream automation and access reviews. In the commodities services engagement mentioned above, an environment with about 250 users and a mixed E3/E5 tenant achieved an Entra Secure Score of 56.71 percent, a figure almost entirely due to these four gaps rather than the result of any one severe misconfiguration. The organization had acquired the correct SKUs; it had just not completed the configuration of the features that those SKUs enable.
The path to implementation is not exciting, but it is sequential. This involves rearchitecting Conditional Access so that it consists of a smaller number of non-conflicting policies, enforcing multi-factor authentication for both administrators and regular users, completely disabling legacy authentication, and then carrying out a full audit of the way roles are allocated among users and service principals. This is why the TrustedTech Copilot Readiness Assessment regards this area as the starting point: since identity is the main entrance, all the other pillars take it for granted that it is already secured.
It should be mentioned explicitly that the company providing commodities services already had the Microsoft Entra ID P2 license, the version that enables risk-based sign-in and Identity Governance. It had just not been put into use. TrustedTech finds this situation more frequently than a complete licensing gap: the organization already possesses the control it needs but has not activated it.
Pillar 2: Threat Protection (Defender)
Copilot increases the value of a compromised account or device since it provides an attacker with a faster search tool after they have gained access. The role of Defender is to stop the compromise from occurring in the first place, or to detect it before Copilot is incorporated into the attack. It is reasonable to ask directly whether Microsoft Copilot itself is secure. The truthful answer is that Copilot inherits the security posture that the tenant already has, which is precisely why this aspect needs to be addressed before the rollout, not after.
TrustedTech regularly discovers cases where Defender for Endpoint is licensed but not actually implemented, which means that companies are paying for protection that they have never turned on. It is also rather common to find that a third-party email security tool situated in front of Defender for Office 365 effectively bypasses it, and that Defender for Cloud Apps is completely left unused, resulting in no insight into the risks associated with SaaS applications. During the same commodities services engagement, Defender’s Secure Score was 78.77 percent, about 22 points higher than the tenant’s Entra score. Endpoint tools tend to perform better than identity hygiene because they are set up once during onboarding and then never reviewed again as the environment expands.
To close this gap it is necessary to put Attack Surface Reduction policies into effect, switch the EDR from audit mode to block mode, deploy web content filtering, and integrate third-party SaaS applications into Defender for Cloud Apps so that shadow IT is not entirely left outside the security perimeter.
Pillar 3: Data Governance (Purview)
It is here that the most significant risk particular to Copilot exists. Since Copilot has no inherent understanding of what constitutes sensitive information, and unless it is told otherwise by Purview, a file is treated as a normal file regardless of whether it contains a lunch order or a customer’s financial records. It is the data governance layer that actually determines what is considered sensitive for all downstream tools, Copilot being one of them.
Across all its assessments, TrustedTech has consistently identified the same six deficiencies: the absence of a structured sensitivity labeling framework, data loss prevention (DLP) policies that operate only in simulation mode rather than enforcing them actively, the lack of retention or lifecycle management (which causes stale data to build up and increases the amount of data that Copilot can retrieve from), the absence of an insider risk management program, DSPM for AI not being enabled (which means there is no visibility into how Copilot itself is interacting with data), and the lack of trainable classifiers, so classification has to rely entirely on manual and inconsistent efforts. The commodities services engagement had all six of these issues at the same time, and that is more in line with the norm than the exception. Purview is usually the pillar that organizations are able to defer, since none of the gaps associated with it lead to an obvious outage like those caused by failures in identity or endpoint systems.
The best place to start is applying sensitivity labels, since all the other Purview settings depend on data having first been classified. After that, take the DLP out of simulation mode and put it into active enforcement, set up retention labels to manage the aging of data, and turn on DSPM for AI so that you have a baseline of what Copilot is actually accessing when it goes live. The one thing most organizations fail to do at this stage is realize that they have an oversharing problem only after Copilot is already live and in use.
Pillar 4: Endpoint Management (Intune)
Copilot data should only be accessible from a device that you trust, and Intune is the mechanism by which that is achieved, or not.
In the evaluations, a pattern reappears: there are no mandatory restrictions regarding device platform, stale or inactive devices remain in the tenant while still having active access, compliance policy enforcement is inconsistent, Autopilot has only been partly rolled out, and Mobile Application Management (MAM) policies are used to a limited extent, with no MAM boundary allowing personal devices to access corporate data. In the commodities services tenant, Autopilot had been tried out on a small number of machines and had never been extended beyond that point, a typical place for pilot projects to stall once the original project team turns to other priorities. None of these shortcomings is something Copilot has caused. On the contrary, each one becomes more significant when Copilot is able to summarize tenant data from any device that can authenticate.
To fix this pillar, compliance policies should be applied across the entire tenant and directly linked to Conditional Access so that non-compliant devices are blocked rather than just flagged. This should be combined with device cleanup rules that automatically delete inactive devices after 30 to 90 days, a finished Autopilot rollout for standardized provisioning, and MAM policies specifically designed for any BYOD population.
Pillar 5: Collaboration Controls (Teams, SharePoint, Exchange)
It is at this pillar that Copilot carries out its daily retrieval activities. The system reads mail from Exchange, conversations in Teams and content from meetings, and documents from SharePoint and OneDrive, so governance across these three platforms serves as the final safeguard against unintentional oversharing.
On Exchange, TrustedTech repeatedly discovers forwarding rules that have never been reviewed, DNS authentication (SPF, DKIM, DMARC) that has not been fully verified, and DLP coverage that falls short of covering email. The commodities services tenant had all of this, together with a few legacy mail-flow configurations left over from an earlier migration that no one had returned to remove. Because Copilot can summarize and display email content on request, an unreviewed forwarding rule is no longer just a phishing risk; it has become a means by which summarized sensitive content can automatically leave the organization.
In Teams, meeting and messaging policies are usually left as the standard defaults rather than tailored to the requirements of the business, which means transcription and retention settings take on whatever Microsoft provides rather than being the result of a deliberate choice. Since Copilot is based directly on the conversations and meeting content in Teams, it makes sense to look at this issue even in organizations that consider their Teams governance complete.
Site ownership models and external sharing settings on SharePoint are generally the most developed of the three, but are seldom completely secure. Most of the remaining gap can be closed by formalizing a system for site owners and managers, implementing standardized governance procedures across all business units, and applying sensitivity labels at the document library level.
The Phased Copilot Readiness Roadmap
TrustedTech sequences remediation across four phases rather than tackling all five pillars in parallel, because identity and data governance are prerequisites for everything that follows:
- Phase 1: Identity and Access (Entra). Enforce multi-factor authentication, simplify and rearchitect Conditional Access, block legacy authentication, and implement least-privilege access.
- Phase 2: Data Governance (Purview). Implement sensitivity labels, put DLP into active enforcement, configure retention policies, and establish insider risk controls.
- Phase 3: Endpoint Security (Intune). Enforce device compliance, use Autopilot to standardize provisioning, and protect data on both managed and unmanaged devices.
- Phase 4: Pilot Program. Carry out a controlled Copilot pilot with a specific user group to verify that security, data access, and adoption function as expected before rolling out Copilot tenant-wide.
In reality, the organizations that go straight to Phase 4 are the ones who end up back at Phase 1 a few months later, this time carrying out incident response rather than planned remediation. The phases are ordered this way because Copilot can’t eliminate a governance gap; it can only make the gap easier for the first person to spot.
Frequently Asked Questions
Q. Does the use of Copilot introduce new security risks, or merely bring existing ones to light?
A. Copilot by itself doesn’t introduce new types of risk. Instead, it speeds up access to the risks that an identity, device, or sharing gap would have already exposed, which is why the maturity of identity and data governance becomes more important after Copilot is introduced than before.
Q. Is it necessary to have Microsoft E5 licenses to close these gaps?
A. Controls such as risk-based sign-in and PIM are P2 features associated with higher licensing tiers. Although many of the most significant fixes, such as MFA enforcement, DLP activation, and device compliance policies, are available at lower tiers, they often go unactivated rather than unlicensed.
Q. How long does a Copilot readiness assessment usually take?
A. TrustedTech’s Copilot Readiness Assessment is usually made up of one or two brief discovery meetings together with an engineering analysis of the tenant’s configuration, after which a written report is produced and a review of the findings is given.
Q. Should we use Copilot before completing all five pillars?
A. A pilot involving a small, well-defined user group can proceed in parallel with later-phase remediation, but identity and data governance (Phases 1 and 2) should be largely complete beforehand. Piloting in an ungoverned data environment mainly shows you what Copilot can see, not how it performs.
Q. What part does Secure Score play in this assessment?
A. Secure Score can serve as a good initial indicator of Entra and Defender maturity, but it is not a full measure of readiness. Since Purview, Intune, and collaboration governance gaps are absent from Secure Score, a Copilot-specific assessment looks at all five pillars rather than depending solely on it.
Where to Start
Most organizations don’t need to work out which of the five pillars is the weakest. A Copilot Readiness Assessment examines all five pillars in relation to your specific tenant setup and provides a step-by-step plan rather than a standard checklist. When leadership has already begun asking about the return on investment or the schedule for Copilot, this assessment is the quickest way to give them an answer based on your own tenant’s data rather than an industry average.
This review was prepared by TrustedTech’s Cloud Solutions Architecture team.
