The practical change is narrow but meaningful: when an investigator exports search results directly from an eDiscovery case, the resulting package can be encrypted at rest with a tenant-controlled key rather than relying solely on Microsoft-managed encryption. Microsoft’s recently updated Purview documentation confirms that the capability applies to export packages backed by tenant-specific encryption scopes through the Microsoft 365 Data-at-Rest Encryption Platform, or MDEP.
For administrators, the important qualification is that this is not a switch that appears in the export wizard and immediately covers every type of eDiscovery data. Microsoft’s own prerequisites show that it requires an established Customer Key deployment, an Azure Key Vault configuration, a Data Encryption Policy in the PolicyAssigned state, and an explicit enablement request through Microsoft Support or a Customer Success Account Manager.
Direct exports are the boundary
Microsoft’s wording can easily be read as a broad eDiscovery encryption upgrade. It is not. The feature covers direct exports from eDiscovery searches: the export route used to take search results to PST files, individual messages, and copies of SharePoint or OneDrive documents without first putting the material through a review set.
Microsoft Learn explicitly says the Customer Key protection does not cover eDiscovery review-set data at rest. That exclusion is consequential because review sets are where organizations often preserve a static collection of material for filtering, tagging, analytics, reviewer work, and production preparation. A legal or investigation team that uses a review-set workflow will not gain the promised tenant-key protection for the copied evidence merely by enabling this direct-export feature.
This splits an organization’s eDiscovery data-handling story in two. Directly exported packages can fall under the Customer Key policy once the service is enabled, while the data retained in review sets remains under Microsoft-managed encryption. Microsoft has a separate roadmap item for Customer Key encryption of review-set data, but its current timing and cloud coverage should not be assumed to match Roadmap ID 565373.
The roadmap date does not tell the whole availability story
The submitted Microsoft 365 Roadmap entry says this capability is in development and targets January 2027 general availability in GCC, GCC High, and DoD. But Microsoft Learn already documents “Enable CMK for direct exports” as a preview capability and provides the operational prerequisites to request access.
A Microsoft 365 Message Center item mirrored by the independent Message Center Archive also described an earlier schedule: preview beginning in May 2026 and general availability beginning in September 2026. Microsoft’s current documentation does not state a specific rollout date or enumerate which sovereign clouds can enable the feature today.
The records are not necessarily irreconcilable. The most likely reading is that the documented preview and earlier rollout refer to the broader service, while Roadmap ID 565373 tracks the later deployment for the U.S. government cloud environments named in the entry. Microsoft has not published enough detail to establish the exact boundary between those timelines, however. Administrators in GCC, GCC High, and DoD should treat January 2027 as the planning date for their tenants, rather than treating the presence of preview documentation as confirmation that their environment can be onboarded now.
That difference matters for compliance teams writing key-management controls. A procedure that promises Customer Key coverage for every Purview direct export before the tenant has received service-side enablement would be inaccurate, even if the organization has already completed its broader Customer Key deployment.
Customer Key is dependent on an existing encryption program
The eDiscovery feature sits downstream from Microsoft 365 Customer Key rather than providing a self-contained key-management setting in Purview. Microsoft says a tenant needs Azure Key Vault configured through the standard Customer Key process and a MDEP Data Encryption Policy that has reached PolicyAssigned.
That means the work is owned by more than the eDiscovery administrator. Security and identity teams responsible for Azure Key Vault, Purview compliance teams, and the legal or investigations group that initiates exports will need an agreed operating model. The technical feature is available only when those components have already been connected and the applicable policy has been assigned.
Microsoft also says the tenant must remain Customer Key-enabled at the time of export. In operational terms, this makes key-policy health a dependency of a time-sensitive legal workflow. If a case team waits until an urgent production deadline to discover that its Data Encryption Policy is not properly assigned, there is no indication Microsoft will silently fall back to the new protection model for that export.
The company has not published a separate SKU, pricing change, export throughput figure, or customer-facing status indicator for this eDiscovery extension. It also has not described a portal control that lets a case manager prove, from the completed export record, which encryption scope protected a specific package. Those omissions leave a gap between being technically configured for Customer Key and being able to document the protection applied to a particular production set.
Export links remain a separate exposure
Encryption at rest protects the data package in Microsoft’s export storage, but it does not eliminate the access-control risks around downloading it. Purview’s export settings can create pre-authorized download links that act as access tokens and allow download tools to resume interrupted transfers without repeated sign-in.
Microsoft warns that anyone who receives such a link can access the export while it is valid. Administrators can set link lifetimes from one hour to seven days, with 24 hours as the documented default. For high-sensitivity investigations, enabling Customer Key while leaving long-lived pre-authorized links broadly shared would solve one part of the chain and leave another exposed.
Search-export packages also expire 14 days after creation and are automatically deleted after that period, according to Microsoft Learn. That deadline remains in force with Customer Key enabled. Encryption does not create a retention exception, recover an expired package, or replace the need to preserve the underlying source data through eDiscovery holds where appropriate.
The direct-export workflow can produce PST files for messages, individual .msg files, and native copies of SharePoint and OneDrive material. Once recipients download and distribute those files, the Customer Key protection described by Microsoft no longer answers the broader questions of local storage, transfer to outside counsel, processing platforms, or production repositories. Teams should keep treating the export package as the beginning of evidence handling outside Purview, not the end of it.
What Purview and security administrators should do now
Organizations in commercial Microsoft 365 environments that already use Customer Key should determine whether Microsoft has enabled CMK for direct exports in their tenant. Microsoft’s documentation is explicit that Support or a CSAM request is required; no amount of role assignment in the Purview portal substitutes for that request.
Government-cloud customers should begin the prerequisite work before the January 2027 target, but should not schedule a legal-workflow dependency on the feature until Microsoft confirms deployment for their specific cloud. The clearest checks are whether Azure Key Vault and MDEP are already in place, whether the relevant Data Encryption Policy reports PolicyAssigned, and whether the tenant has received confirmation that the direct-export feature itself is enabled.
They should also map which cases use search-to-export and which rely on review sets. The distinction determines whether this enhancement applies at all. A team that regularly stages evidence in review sets should not tell regulators, counsel, or internal auditors that eDiscovery exports are universally covered by tenant-managed keys; Microsoft’s current documentation says the protection stops short of that workflow.
Microsoft’s January 2027 government-cloud rollout, if it arrives on the roadmap schedule, will give GCC, GCC High, and DoD customers a stronger control over a particularly sensitive point in Purview’s evidence pipeline. But the benefit is precise: it protects direct-search export packages at rest under the tenant’s Customer Key configuration. It does not yet encrypt review-set storage with those keys, and it does not remove the need to control download links, recipient access, and the evidence copies created after export.
