Official documentation checked October 14, 2026.
Microsoft 365 Copilot can be part of a Customer Key deployment, but “bring your own key” is not a single switch that makes the entire AI service private or gives you an instant, universal shutoff. The useful question is which stored data must use customer-controlled root keys, and whether your organization can operate those keys safely.
This article is a readiness and design guide for Microsoft Purview Customer Key. For resource-level checks, see Azure Key Vault configuration for Customer Key. Consumer Copilot settings, Copilot Studio environment encryption, and an application’s own Azure encryption configuration are separate topics.
1. Map the encryption requirement to the correct data
Microsoft includes Microsoft 365 Copilot interactions in the multi-workload data encryption policy, or DEP. SharePoint and OneDrive file data are not included in that DEP; they require the separate SharePoint policy. Source content and an interaction that refers to it therefore need separate coverage checks. Microsoft’s Customer Key overview lists the policy boundaries.
Customer Key concerns encryption at rest. Microsoft 365 still uses the keys to deliver authorized service functions; this is not a design in which Microsoft is technically unable to process any content. Existing service encryption also means that choosing not to deploy Customer Key does not leave ordinary Microsoft 365 data unencrypted.
Make a short coverage record before seeking approval: the data category, storage workload, required DEP, responsible owner, and evidence that the policy applies. Include both the Copilot interaction and any sensitive source documents in your example. Do not label all Microsoft Graph-accessible information as covered merely because Copilot can reference it.
The availability-key architecture adds a further distinction: SharePoint Customer Key protects file data in blob storage, not list items and metadata in SQL. A broad promise that it covers every SharePoint object would therefore be misleading.
2. Budget for licensing and ongoing key ownership
Review Customer Key entitlement separately from a Copilot subscription. Microsoft’s current licensing rules count the users benefiting from the workload. For multi-workload policies, the eligible Customer Key license count must cover the greater of the Exchange-licensed and Teams-licensed user counts. SharePoint has its own count based on SharePoint-licensed users. Confirm the applicable plans and agreement with your licensing owner using the Purview service description.
The deployment also needs Azure resources and people who can maintain them. Budget for the selected vault or HSM configuration, monitoring, backups, approved changes, and support coverage. Avoid a fixed monthly estimate without the intended region, resource type, workload, and usage.
Name a service owner, key custodian, backup custodian, change approver, and recovery contact. Decide who can change service access and who can authorize a destructive action. These may be separate people or controlled roles, but the responsibilities must not disappear when one administrator leaves.
Before resource creation, review the current onboarding prerequisites for your tenant and cloud. Record the planned two-key architecture and workload-specific onboarding path. Do not assume that all clouds or SharePoint onboarding use the same automation. Treat a technical validation result as one release gate, not as approval to change production encryption.
3. Plan rotation and recovery without using revocation as a test
Agree in advance what constitutes normal rotation, suspected compromise, accidental key loss, and planned service exit. They require different responses. Creating a new version in Azure is not necessarily the entire rotation: the relevant service policy must be updated and its state verified.
Microsoft’s rotation guidance warns against deleting or disabling keys, including old versions associated with encryption policies. Older material can be needed for recovery. Keep that dependency visible in your retention and backup plan; never purge keys because a fixed number of hours has elapsed in a generic tutorial.
Customer Key also uses an availability key protected by Microsoft service code. Recovery and fallback behavior differ by workload: SharePoint requires an explicit recovery request for availability-key use, while Exchange and multi-workload services have other documented fallback behavior. Cached key material and service-specific handling mean revocation is not a reliable instant shutoff for every Copilot-related operation. See the availability-key explanation.
Rehearse the contact and recovery decision process without disabling production keys. Verify who can access the backup record and open the required support case. If you need an actual recovery exercise, design it with the service owner and Microsoft support in a suitable isolated scope.
Document rollback and data purge separately. Microsoft’s policy-management guidance says rollback does not delete data, and multi-workload DEP purge is not supported. Customer Key is not a shortcut for deleting one user’s Copilot history or bypassing a retention obligation.
4. Define evidence for approval and continuing operation
Ask the security or compliance owner which requirement Customer Key is intended to meet and what evidence is acceptable. A product feature does not automatically certify your deployment, satisfy every legal duty, or replace access control, retention, monitoring, and incident response.
For a practical approval packet, capture the mapped data scope, verified licensing, approved architecture, operator roles, successful onboarding result, actual policy assignment, and workload status. Use the real verification commands in the policy-management guide; do not rely on a nonexistent Get-M365CustomerKey command or a supposed universal “Copilot BYOK active” badge.
Then test an ordinary authorized workflow and its access boundary without revoking keys. For example, confirm that the selected users can perform their approved task and that a user without source access does not gain it. This checks the access design, not the encryption algorithm; record the distinction.
Approve rollout only when the data coverage is explicit, operational ownership exists, and recovery and change procedures have been reviewed. If the actual objective is to fix excessive file permissions or prevent an agent from sharing another user’s data, address that access problem directly. Adding customer-controlled encryption keys does not repair it.