Microsoft Purview in Late 2026: Legacy Office Files, Network DLP and AI Data Security

Building on my earlier Purview article on data security and compliance, one of the October roadmap announcements caught my attention for a fairly ordinary reason. It concerns old Word documents, Excel spreadsheets and PowerPoint presentations. The files that survive several migrations because nobody wants to touch the business process that still depends on them.

Roadmap 574363 plans to extend service-side auto-labeling to .doc, .xls and .ppt files in SharePoint and OneDrive. As of October 31, the roadmap still lists this as in development, with preview and general availability targeted for November 2026. That is a planned change, not a capability I would assume is already running in every tenant.

The connection to AI is practical. Microsoft 365 Copilot makes information easier to find and combine within the user's permitted access. If an organization has spent years classifying new documents while leaving historical material poorly understood, that gap has consequences. A file doesn't become less sensitive because it was created in an older version of Office.

There is also a budget question before any deployment. Auto-labeling, Endpoint DLP, connected-app protection and network inspection have different entitlements and prerequisites. Check the Purview service description against the users, workloads and integrations you intend to cover. An existing Microsoft 365 subscription doesn't prove that every feature below is included.

What has shipped, and what is still planned

Microsoft's Purview release notes separate released capabilities from previews. The roadmap adds future targets. I would keep those two sources separate when planning changes, because a release month and a tenant's actual availability aren't the same thing.

Roadmap dates can change. Check the feature in your own tenant and read its Message Center notice before scheduling enforcement, promising coverage or changing a compliance control.

Old Office files need a deliberate rescan

The legacy-format update addresses a particular gap in service-side auto-labeling. It doesn't mean that legacy files have never had any protection, or that every old file will now qualify for every label. The policy still needs supported content, matching detection conditions and the correct SharePoint or OneDrive scope.

Microsoft's Message Center notice MC1530948, available in this public mirror, gives a useful operational detail. New policies will support the added formats without an extra policy edit. Existing policies require a small edit, a save and another run to restart the crawl. Adding or removing a policy comment is the example in the notice. Confirm the notice in your tenant's Message Center as well.

The notice schedules public preview from early to mid-November and GA in late November. Both simulation and enforcement are included in the described support. I would start with simulation, not broad automatic labeling of an archive that hasn't been assessed recently.

1. Identify the libraries and OneDrive locations with historical Office content. Record file counts, owners and the sensitive-information types you expect.
2. Review the existing policy scope and label settings. Check what the label actually does, including encryption and permitted usage.
3. After the feature reaches the tenant, edit and save each existing policy that should cover legacy files, then run it again as the notice directs.
4. Review simulation matches, sample false positives and verify that legacy formats were evaluated. A successful policy run alone doesn't establish coverage.
5. Enable enforcement for an agreed scope, then check representative files and downstream applications for the intended result.

The auto-labeling documentation is the place to check current prerequisites and limitations. File eligibility, processing and label behavior still matter. I wouldn't use a new format checkbox as evidence that the organization's historical information is now fully classified.

A policy needs to cover the actual data path

Network Data Security connects Purview classification and policy evaluation to a network enforcement point. Microsoft's September release notes list the integration with Microsoft Entra Global Secure Access as generally available. It covers supported text, file and AI interactions through browsers, applications, APIs and add-ins.

This is a different control from protecting files at rest in SharePoint. Consider an employee uploading a customer export to an external AI website. A policy covering the SharePoint library doesn't automatically govern the later transfer. Endpoint and network controls can address that movement, provided the device, traffic route, destination and operation are within their supported scope.

In the Network Data Security guidance, licensing depends on the integration. The Entra Global Secure Access route has its own per-seat combinations; the documentation does not require pay-as-you-go setup for that integration. Non-Microsoft SASE and secure-browser integrations require the applicable Purview entitlement and pay-as-you-go billing. Check the current requirements instead of applying one cost model to every route.

Traffic steering and inspection also need a deployment design. Verify supported traffic, TLS inspection requirements, exceptions and privacy obligations for your selected integration. Audit a pilot first. Then test an allowed transfer and a blocked transfer, and confirm the action and event record rather than trusting the presence of a configured policy.

Roadmap 575285 plans policies targeting all websites, or all websites except specified cloud apps, including destinations outside the Defender Cloud App Catalog. That broadens targeting. It doesn't remove inspection limitations or make every unsteered connection observable.

Box and Google Workspace are not just extra Microsoft 365 locations

August brought previews for DLP in non-Microsoft connected apps and sensitivity label policies for connected apps. Both use Microsoft Defender for Cloud Apps connectors. That gives organizations a way to apply familiar classification conditions to supported data at rest outside Microsoft 365.

The app lists are not identical. The auto-labeling documentation lists Box and Google Workspace. The DLP documentation lists a broader set, with phased tenant availability. I would verify support separately for detection, labeling and each enforcement action rather than copying a product list between policies.

There are concrete configuration restrictions. The DLP preview requires a Custom policy, doesn't support Administrative Units for non-Microsoft app locations, and doesn't combine those locations with SharePoint, OneDrive, Exchange, Fabric or Devices in the same policy. A common classification engine is useful, but it doesn't mean there is one interchangeable policy for every workload.

For a pilot, connect one approved app instance, confirm the connector's permissions and start with a small content scope. Test the exact file types and actions your business uses. Include recovery from a mistaken restriction in the test, not just successful detection.

Delegated Copilot administration is useful, but limited

Roadmap 575287 extends Administrative Units support to supported DLP policy management for Microsoft 365 Copilot, Copilot Chat and Cowork. It lists an October preview target and November GA target, while still reporting in development on October 31.

The purpose is delegated administration within assigned organizational scopes. A regional administrator can manage supported policies without tenant-wide policy-management permissions. The roadmap explicitly says existing tenant-wide policies continue to apply and the AU-scoped configuration is optional.

That is an administrative boundary, not proof that a Copilot session or an agent is isolated to that unit's data. Source permissions, label protection and applicable policies still decide access and use. It also doesn't contradict the separate connected-app preview limitation: AU support is workload-specific.

FTP transfers and alert decisions still matter

The October GA addition for FTP and SFTP transfers applies to managed Windows devices onboarded to Purview. Endpoint DLP evaluates the activity against configured rules. It doesn't decrypt SSH traffic at a network gateway; it observes a supported endpoint operation.

In the Purview portal, create or update a Devices-scoped DLP rule, choose Audit or restrict activities on devices, then select FTP and SFTP transfers under the relevant file activities. The documented actions include Audit only, Block, Block with override and Allow. Start with Audit only and inspect Activity explorer before applying a restrictive action to a production workflow.

Full file evidence can save a complete copy of a matched file when configured. That is useful for an investigation, but it also creates another sensitive copy. Restrict investigator access, agree retention requirements and check evidence collection prerequisites before enabling it broadly.

Roadmap 576710 plans Insider Risk Management alert classification as True positive, Benign (operational) or False positive. Authorized analysts choose predefined classification reasons, replacing the existing dismissal reasons. Preview is targeted for November; GA is targeted for January 2027.

I would use that change to agree what each classification means operationally. Track reviewed alerts, time to a decision and repeated false-positive causes. More detections are only useful if someone can explain the risk and act on it. My earlier Purview DSI and Entra response article connects the investigation to identity-side remediation.

Labels can protect content, but they don't repair permissions

A sensitivity label can be classification metadata, or it can apply encryption and usage restrictions. Those protected-content rights are access controls. It would be wrong to suggest that labels never affect who can open a file. The distinction is that applying a label doesn't automatically correct an overbroad SharePoint permission, an overly privileged agent identity or an API that authorizes the wrong operation.

Data classification tells us what information needs protection. Authorization decides whether a particular identity can read it or perform an operation. DLP evaluates supported use or movement of that data. An investigation explains what happened and whether the response reduced the risk. These are related controls with separate responsibilities.

Consider a finance agent that can read an archive and submit changes to an accounting API. Purview may classify the archive and govern a supported transfer, but it doesn't establish whether the agent should approve a payment. That authorization belongs in the application and the identity behind its tool call, with approval where the business operation requires it.

My next steps would be to measure the legacy classification gap, test the actual outbound paths, review source permissions and assign owners to the policies and agent identities. Then keep evidence of permitted and denied behavior. No AI without security, and no security architecture without identity.

Related posts

• Microsoft Purview: data security and compliance
• From alert to action with Purview DSI and Entra ID