Microsoft Purview is adding customer-managed key protection to eDiscovery direct exports, giving organizations that already operate Microsoft 365 Customer Key a way to place their own encryption keys around exported investigation packages. The Microsoft 365 roadmap entry, ID 557684, says general availability is planned for December 2026, with a preview listed for April 2026.

There is an important timing wrinkle: Microsoft’s current Purview documentation already labels the capability “preview” and provides the prerequisites to request enablement. In other words, the roadmap still calls the item “in development,” but the operational documentation indicates that a controlled preview is already available to qualifying tenants. The practical read is that this is not a switch that administrators should expect to find automatically in the Purview portal; it is a gated feature that requires Microsoft involvement.

For legal, compliance, and security teams handling sensitive collection data, the change addresses a specific gap in the eDiscovery workflow: the protection of the exported package after an investigation has moved from search and review into download and handoff.

Digital document security system showing encrypted files, cloud storage, access controls, and a user managing downloads.Direct-export packages gain a tenant-controlled encryption layer​

Microsoft’s roadmap description is brief: customer-managed key, or CMK, options will be added to data included in eDiscovery’s direct-export workflow alongside the Microsoft-managed encryption already used by the service.

Microsoft Learn fills in the implementation detail missing from the roadmap. When CMK is enabled for direct exports, Microsoft says eDiscovery export packages are encrypted at rest using tenant-specific encryption scopes backed by customer-managed keys. Those keys are managed through Microsoft 365 Customer Key and the Microsoft 365 Data-at-Rest Encryption Platform, known as MDEP.

This is a meaningful addition for organizations whose investigation material includes employee communications, mailboxes, Teams messages, SharePoint documents, OneDrive files, or other records collected under legal hold. An eDiscovery export can become one of the most concentrated copies of sensitive tenant data: a packaged dataset assembled expressly for legal review, outside counsel, an internal investigation, or regulatory production.

Microsoft-managed encryption still protects Microsoft 365 data as a baseline. Customer Key changes the control model for organizations that need to own the key material used to protect particular Microsoft-hosted data. It does not mean Microsoft sends encrypted export archives to a customer for local key handling, nor does it convert the export process into end-to-end encryption. The feature concerns Microsoft-hosted export packages at rest before their retrieval.

Microsoft’s documentation narrows the scope sharply​

The first operational limit is also the most important one: Microsoft says CMK protection applies to direct exports only. It does not extend to data at rest in an eDiscovery review set.

That distinction matters in an investigation workflow. Review sets are where collected records can be filtered, tagged, analyzed, redacted, and prepared for production. Direct exports, by contrast, are downloadable packages generated from searches or exports that administrators and case members retrieve from Purview. An organization cannot treat this roadmap item as a blanket promise that every eDiscovery artifact will be wrapped by a tenant-managed key.

Microsoft also says the tenant must remain CMK-enabled at the time an export is created. That is more than a setup footnote. Teams planning a Customer Key redesign, a policy reassignment, or key rotation should test how those changes interact with active legal matters and scheduled exports. A tenant that removes or disrupts the underlying CMK configuration at the wrong time could find that its export procedure no longer works as expected.

Microsoft’s broader Customer Key documentation warns that expired keys cannot be used and that operations involving them can fail, potentially causing service outages. In the eDiscovery context, that turns key lifecycle management into a legal-operations dependency. A missed key-expiration review could land during a court deadline, regulator request, or internal incident response, exactly when the organization needs to export records quickly.

This preview requires more than a Purview administrator​

The preview is not currently described as self-service. Microsoft Learn directs customers to contact Microsoft Support or their Customer Success Account Manager to request CMK for eDiscovery direct exports for the tenant.

Before that request can be useful, Microsoft requires three conditions:

  • The tenant must have the CMK direct-export feature explicitly enabled by Microsoft.
  • The organization must have completed the standard Microsoft 365 Customer Key configuration through Azure Key Vault.
  • A Data Encryption Policy must be in the PolicyAssigned state through MDEP onboarding tools.

This places the change squarely in the hands of a joint compliance, identity, and Azure infrastructure effort. A case manager with eDiscovery permissions will not be able to turn it on independently. The work involves Azure subscriptions, key-vault or managed-HSM administration, Microsoft Entra service principals, Exchange Online PowerShell for data encryption policy operations, and Purview eDiscovery administration.

Microsoft’s Customer Key setup guidance requires two paid Azure subscriptions for its standard configuration and recommends separating key management responsibilities between different people. It also requires two keys for each Data Encryption Policy. Those requirements are designed to reduce the risk that one administrative mistake or one compromised administrator can render protected Microsoft 365 data inaccessible, but they also add cost and operational overhead.

For organizations that already run Customer Key for other Microsoft 365 workloads, the direct-export preview may be an extension of an existing control plane. For tenants without Customer Key, it is not a lightweight eDiscovery feature toggle. The roadmap entry does not state whether Microsoft will introduce separate licensing, whether current Customer Key eligibility is sufficient for every eDiscovery tenant, or whether the preview has capacity limits. Microsoft’s current documentation does not answer those questions either.

The download link remains a separate exposure point​

Encryption at rest for an export package does not eliminate the access-control risks created once an authorized user starts a download. Microsoft’s eDiscovery export settings documentation warns that pre-authorized export links grant direct access to the export and should be treated as secrets. Anyone who obtains a valid link can access the package during its configured validity period.

Administrators can set the availability of pre-authorized download links from one hour to 168 hours, with 24 hours as the default. Microsoft recommends selecting the shortest duration that is practical for the size of the export. The company also notes that disabling pre-authorized links forces a signed-in download flow, reducing token-sharing risk, but downloads may not resume after interruption.

That creates a real tradeoff for large legal exports. Long-lived, resumable links make difficult downloads more reliable, especially on constrained networks. They also extend the period in which a forwarded, copied, or otherwise exposed link can be used to pull sensitive investigation data. CMK encryption of the package at rest does not change that link’s role as an access token.

Organizations evaluating the preview should therefore pair it with a review of export-download settings, case membership, link duration, endpoint controls, and procedures for transferring productions to outside counsel or review platforms. The highest-risk moment may still be when the package leaves the Microsoft-controlled service boundary.

What administrators should do before December​

Microsoft lists worldwide standard multi-tenant availability for the feature. It does not list Government Community Cloud, GCC High, DoD, or sovereign-cloud availability. Administrators in those environments should not assume the worldwide roadmap target applies to them; Microsoft’s current export-settings documentation separately notes that pre-authorized download links are unavailable in DoD cloud organizations, illustrating how eDiscovery controls can vary by cloud.

The immediate task for Customer Key customers is to validate their existing foundation rather than wait for the roadmap date. Confirm that the MDEP policy is actually in PolicyAssigned status, check that key-vault permissions and Microsoft service principals are configured correctly, and verify that the designated keys will not expire during active matters. Security teams should also make sure their recovery and backup procedures for key material are documented and tested.

For organizations that do not use Customer Key today, the more useful planning question is whether the export-package scenario justifies the administrative burden. The answer is most likely yes where legal productions contain regulated data, where contractual obligations require tenant-controlled encryption keys, or where a security policy treats investigation exports as a distinct high-value data class. For other tenants, Microsoft-managed encryption plus tightly controlled export permissions and short-lived download links may remain the more manageable design.

Microsoft’s December 2026 general-availability target is the next published milestone. Until Microsoft clarifies licensing, supported cloud instances beyond worldwide multi-tenant, and the final enablement path, the safest conclusion is that CMK for eDiscovery direct export is a valuable but narrowly scoped control: it protects the downloadable package in Microsoft’s service, while leaving review-set protection and the operational security of the eventual download as separate problems for the customer to solve.