That change sounds subtle, but it could alter how Microsoft 365 organizations identify dormant material, structure preservation rules, and prepare records for eventual disposition. It is also a feature where the operational details matter more than the headline. The announced rollout is still future-facing, the first release is narrower than the name suggests, and Microsoft has not yet described exactly what activity will count as access.
What Microsoft has announced
A Message Center notice updated September 10, 2026 says Purview administrators will be able to apply retention policies or retention labels to OneDrive and SharePoint files that have not been accessed by anyone in the organization for a specified time. The key distinction is that the proposed condition concerns access, not merely a document’s creation date or the date someone last edited it.
The updated notice places preview from late November through December 2026. Worldwide general availability is then scheduled to start in early January 2027 and complete by early February 2027.
Those dates should be treated as a deployment plan rather than a promise that every tenant will receive the setting on a particular day. The notice had its timeline updated, and Microsoft 365 feature schedules can change. Organizations should therefore plan for evaluation and testing during the stated window, without building compliance deadlines around a fixed February delivery date.
The notice also says the capability will be available by default. That wording should not be read as meaning that files will suddenly be retained or deleted according to last access. Availability means the control is expected to be present for administrators to use; an organization still has to choose the setting while configuring applicable labels or policies.
Why last access is different from existing retention choices
Current Microsoft guidance documents several ways a retention period can begin. Administrators can base it on when content was created, or—where supported for files in SharePoint, OneDrive, and Microsoft 365 Groups—when it was last modified. Retention labels can also use the date content was labeled and, in relevant configurations, an event-based start.
A last-accessed option would add a materially different lens. Creation-based retention follows the age of the item. Modification-based retention follows the age of its latest change. A last-access condition would instead focus on whether the organization still interacts with the content.
Consider a project document created years ago but edited last month only to correct a heading. A creation-based rule regards it as old; a modification-based rule regards it as recent. Neither answer necessarily tells an administrator whether the document continues to be consulted. Conversely, a file may be actively opened for reference without anyone changing it. Inactivity-based retention could be useful precisely because it distinguishes a long-lived reference document from a file that has become operationally dormant.
That does not mean last access is automatically a better compliance signal. A file can be important even if it is seldom opened: closed matters, legal documentation, intellectual-property records, completed contracts, or evidence connected to a long-running dispute are obvious categories where inactivity alone can be misleading. The new trigger, if released, should be treated as an additional lifecycle tool, not a substitute for a retention schedule based on regulatory, legal, contractual, or business-record requirements.
Initial scope: Microsoft 365 file types only
The announced first scope is limited to Microsoft 365 file types. Support for non-Microsoft 365 file types is planned for a later rollout.
This boundary has practical implications for mixed repositories. A SharePoint or OneDrive library can contain more than Office documents, and organizations should not assume a rule based on last access will initially apply uniformly across every file extension they store. A records manager designing a rule around inactivity may need separate treatment for content outside the supported Microsoft 365 file category until Microsoft specifies broader support.
The limitation also means that testing should use representative files, not just a single Word document. Teams should verify which of their routinely stored content falls inside the initial scope before concluding that an inactive-content policy covers a whole site, library, department, or retention category.
The questions administrators still need answered
The announcement establishes the broad condition—files not accessed by anyone in the organization—but leaves important implementation questions open. It does not state which events reset the clock. Opening a document is an intuitive candidate, but the available announcement does not confirm how viewing, previews, downloads, guest activity, automated applications, or service accounts will be treated.
That ambiguity matters because the answer could materially affect results. If an automated process counted as access, a file could appear active even when no employee has read it. If certain forms of viewing did not count, an organization might see a document categorized as inactive even though users believed they were consulting it. Until Microsoft publishes exact semantics, administrators should avoid making assumptions about the meaning of “last accessed.”
There is a related technical caution for Windows and Microsoft 365 administrators who are accustomed to examining file properties through automation. The announced Purview control should not be equated with a universally exposed file metadata field that scripts can query. The available evidence does not establish an administrator-facing API method for retrieving the signal on SharePoint Online or OneDrive for Business items. In particular, organizations should not design reporting or validation workflows on the assumption that the proposed Purview decision can be replicated from a standard Graph last-access timestamp.
The practical consequence is straightforward: test the Purview behavior itself when preview arrives. Do not presume that a PowerShell, Graph, or third-party inventory process will show the same status or support the same logic.
How to prepare without overcommitting
There is useful work to do before the feature appears, but it should be preparatory rather than irreversible.
First, inventory current retention configurations that begin from creation or last modification. Identify policies where the real business objective is inactivity. Those policies may be candidates for redesign, but they should not be changed until the new condition is available and tested.
Second, separate genuinely dormant working content from records that must be preserved regardless of user activity. A policy for low-value working drafts may sensibly rely in part on inactivity. A policy covering finance, personnel, security, legal, or regulated records should be grounded in the governing retention obligation instead. The fact that nobody opened a file recently does not establish that the file is eligible for disposition.
Third, create a controlled test set covering supported Microsoft 365 file types and the ways people actually interact with documents. Include files that are edited, files that are only read, files with no activity, and content used by business processes. The goal is not merely to confirm that the control exists, but to determine whether its outcomes align with the organization’s understanding of access.
Fourth, involve compliance owners, records managers, SharePoint administrators, and business stakeholders. A setting that looks like a storage-cleanup mechanism can have legal and operational consequences once tied to retention labels or policies. Site owners in particular may know whether seemingly dormant files are retained for periodic audits, seasonal work, or reference.
Finally, document any assumptions made during a preview. If Microsoft later clarifies the access events that qualify, organizations will need to compare those details with their test plan and potentially adjust their configurations.
Government-cloud timing remains unclear
There is a separate source of uncertainty for government customers. A partner roadmap roundup from August 2026 associated a similarly named Purview capability with GCC, GCC High, and DoD, identified it as Roadmap ID 565866, and attached an August 2026 release tag. That conflicts with the later Message Center schedule for a worldwide preview beginning in late November 2026 and general availability running into early February 2027.
The conflict does not establish that the planned feature has already arrived in government clouds, nor does it prove that government tenants will receive it on the worldwide timetable. The two references could reflect different cloud-specific roadmap entries or an outdated schedule, but the available material does not confirm their relationship.
Government-cloud administrators should therefore not infer availability from the August partner listing, and they should not assume the worldwide notice settles GCC, GCC High, or DoD deployment timing. Tenant-specific Message Center communications and the configuration interface remain the more reliable operational checkpoints once rollout approaches.
A potentially useful trigger, not a retention strategy by itself
Retention based on last access could make Purview more responsive to the actual lifecycle of collaborative files. For teams managing extensive OneDrive and SharePoint estates, it may help distinguish content that is merely old from content that has ceased to be used. That has potential value for information governance and for reducing the tendency to use last modification as a rough proxy for relevance.
But the feature’s real value will depend on details that are not yet announced: precisely what counts as access, how the condition behaves across common workflows, how broadly file-type support expands, and when particular cloud environments receive it. The sensible approach is to regard the coming release as a new classification input. It can inform carefully designed retention rules, but it cannot by itself determine whether a business record should be kept, reviewed, or eventually deleted.
For now, organizations should review existing rules, identify appropriate low-risk test scenarios, and wait for the actual Purview control and its accompanying documentation before altering production retention decisions.