Zero Trust is now the reference framework for enterprise cybersecurity. Its three principles, explicit verification, least privilege, and assume breach, are well established for identity security: MFA, Entra Conditional Access, privileged account management. Execution still falls short on the data layer.
According to Gartner (January 2023), only 10% of large enterprises will have a mature Zero Trust program in place by 2026, and more than half of cyberattacks will target areas not covered by Zero Trust controls. In most M365 tenants, open SharePoint shares, active anonymous links, and public Teams groups coexist with strong authentication and a well configured Entra ID. Zero Trust for identity is in place. Zero Trust for data is not. This guide breaks down how to translate the three Zero Trust principles into concrete actions for Microsoft 365 data governance.
According to Microsoft (Learn, 2026), Zero Trust rests on three core principles for data protection.
Explicit verification requires authenticating and authorizing based on every available data point, including data classification, user identity, and behavioral anomalies. Least privilege means limiting access through just-in-time and just-enough-access approaches, protecting both data and productivity. Assume breach requires minimizing blast radius, verifying end-to-end encryption, and using analytics to detect threats.
These three principles apply differently to identity and to data. A tenant can meet explicit verification for sign-ins (MFA, Conditional Access) while still failing explicit verification for data access, if nobody checks whether a SharePoint share created two years ago is still justified.
Microsoft defines five components for a Zero Trust data strategy through Purview: classification and labeling, information protection, leak prevention, insider risk management, and lifecycle governance for sensitive data (Microsoft Learn, 2026). That last point, lifecycle governance, is exactly what's most often missing in M365 organizations.
Zero Trust for data isn't just about encrypting sensitive files. It requires knowing who has access to what, cutting that access down to what's strictly necessary, and periodically verifying that every access right is still backed by a documented business need.
In an M365 tenant without rigorous access governance, permissions pile up mechanically over time. A share created for a project rarely gets revoked when the project ends. A Teams group left open "by default" stays open for years. An anonymous link shared with an external partner stays active long after the contract ends.
According to the Microsoft State of Cloud Permissions Risks report (2023), less than 2% of permissions granted to cloud super identities are actually used. The remaining 98% form a dormant exposure surface, and dormant permissions are exactly what Copilot and AI agents amplify mechanically, by reaching everything a user is technically entitled to, including access rights forgotten years ago.
This debt isn't a technical problem. It's a governance problem. IT teams can flag at-risk shares using SharePoint Advanced Management or Microsoft Purview DSPM. They can't decide on their own whether a share is still needed. That decision belongs to the data's functional owner. This is exactly why explicit verification, applied to data, requires a human decision loop under Zero Trust, not just a technical policy.
In an ungoverned M365 environment, the gap between what Zero Trust requires at the data layer and what's actually in place is the first exposure surface left uncovered by identity Zero Trust controls.
Applying least privilege to M365 data starts with a full map of active permissions. According to Microsoft (Learn, 2026), you can't adequately protect sensitive data without first inventorying and classifying it.
Four access categories make up most of the exposure surface in an M365 tenant.
Anonymous shares and active external access on SharePoint and OneDrive let any external user reach files without authentication, a direct violation of the Zero Trust explicit verification principle.
Microsoft 365 and Teams groups open to "Everyone in the organization" give every employee read access to published content, regardless of sensitivity.
Uncertified external access covers guest users who keep their permissions after a collaboration ends. Keeping that access can't be justified without a functional review.
Inherited permissions on SharePoint subsites create situations where users retain access to sensitive spaces after leaving a project or a team.
The native tools available for this mapping are SharePoint Advanced Management (SAM) data access governance reports and Purview DSPM (E5) for sensitive data inventory. On an unaudited tenant, these four categories account for most of the least privilege violations Zero Trust requires you to fix.
Zero Trust requires explicit verification of every access right. For M365 data, that verification can't be fully automated. It requires the person functionally responsible for the data to confirm whether an access right is still justified.
This is the principle behind access rights reviews: every access right that's kept should be backed by a documented owner decision, not by default inaction. This approach also produces the audit trail that frameworks like NIST CSF and CISA guidance call for, a dated, traceable log of functional decisions.
The limit of pure IT approaches shows up right here: an M365 admin can flag an overexposed SharePoint site through SAM or Purview, but can't decide whether the share with an external development team from eighteen months ago is still needed. Only the functional owner can make that call.
According to IDECSI data (2024), gathered across more than one million users supported on the platform, a recertification campaign involving functional owners produces an average of 7 permission corrections per user in 4 to 6 weeks. Cergy-Pontoise Agglomeration eliminated 50% of its risks in its first DETOX campaign, and 70% after the second, without pulling in extra IT resources.
In a data Zero Trust approach, periodic access recertification by functional owners is the data-layer equivalent of the continuous risk reevaluation that Entra Conditional Access applies to identities. It's the explicit verification loop, applied to the data layer.
The third Zero Trust principle, assuming a breach can happen at any time, requires continuous monitoring of access to sensitive data, not just incident response.
In M365, three monitoring layers map to this principle. Real-time alerting on access to sensitive or critical data, HR records, financial data, intellectual property, catches anomalous behavior before it turns into an incident. Defender for Cloud Apps covers this for user behavior.
Monitoring of Copilot and AI agent interactions is covered by Purview DSPM for AI (GA late May 2026): it logs prompts and responses, flags unjustified access to sensitive data, and alerts on risky agentic behavior.
Detecting reactivated dormant access, a user who suddenly opens a SharePoint site they haven't touched in two years, is a potential breach signal that only access history can surface.
Assume breach, applied to M365 data, means monitoring doesn't stop at authenticated identities. It covers what those identities do with their access, and that monitoring has to be continuous, not periodic.
Zero Trust Principle | M365 Data Translation | Concrete Action | Tool
Explicit verification | Every access right must be functionally justified | Periodic recertification campaigns by owners | IDECSI Access Review / SAM
Least privilege | Remove every unjustified access right | Fix anonymous shares, public groups, stale external access | DETOX / Purview DSPM
Assume breach | Continuously monitor access to sensitive data | Real-time alerting, Copilot/agent logging, anomaly detection | Permission Explorer / Purview DSPM for AI / Defender
Zero Trust for data in Microsoft 365 isn't an extension of identity Zero Trust. It's a distinct layer, with its own requirements and its own tools. It demands three things that technical policy alone can't deliver: a map of existing access, periodic functional verification by data owners, and continuous monitoring of access behavior.
Organizations that have rolled out MFA and Entra ID have covered identity Zero Trust. Those that haven't yet run a remediation and recertification campaign on their M365 data still have a Zero Trust gap on the most exposed layer of their tenant, and it's exactly the layer Copilot and AI agents amplify.
To establish the Zero Trust state of your M365 data and identify priority actions, a DETOX diagnostic maps active permissions and sizes the right recertification plan.