Official documentation checked October 14, 2026.
For Microsoft 365 Copilot, bring-your-own-key planning should start with Microsoft Purview Customer Key and the correct data encryption policy, or DEP. There is no generic Copilot switch that connects one Azure key and automatically protects every document, index, prompt, and response in your organization.
This guide is an administrator’s configuration and verification checklist for Azure Key Vault-backed Customer Key. It is not a consumer Copilot setting, and it does not replace Microsoft’s workload-specific onboarding procedure. Keep existing production keys and access in place throughout preparation.
1. Select the workload before creating resources
Microsoft lists Microsoft 365 Copilot interactions under the multi-workload DEP. SharePoint and OneDrive file data use a separate SharePoint DEP; individual Exchange mailbox policies are another distinct option. A Copilot conversation that references a file does not make the file part of the multi-workload policy. See the Customer Key coverage overview.
Record the target tenant, cloud, workload, responsible service owner, and existing policy before proceeding. If the requirement also includes source files, add their actual storage workload to the design rather than assuming Copilot coverage includes them.
Confirm both the eligible plan and the required number of licenses with the licensing owner. One licensed administrator is not a substitute for licensing the users covered by the feature. Use the current Customer Key licensing requirements.
2. Prepare and inspect the Azure Key Vault resources
The documented setup uses two paid Azure subscriptions in the tenant and two customer keys per DEP. For the Key Vault route, check the vault pair, workload-specific topology, RSA-key requirements, backups, and recovery controls against the Customer Key setup runbook. Premium HSM-backed keys are Microsoft’s production recommendation; Managed HSM is a separate setup path, not simply another name for a Premium vault.
Build an inventory containing each subscription, vault, key name and URI, key version, permissions owner, and backup location. Record identifiers securely; do not export private key material into a deployment worksheet or support ticket.
Customer Key requires soft delete and purge protection with the required recovery period. Check those properties rather than assuming a newly created vault has every protection enabled. Azure explains that soft-delete retention is fixed when the vault is created, while purge protection can be enabled on a suitable existing vault. Do not delete and recreate a production vault because a tutorial says protection can never be added later. See Key Vault recovery behavior.
The current Customer Key Onboarding Service accepts keys without an expiration date. That requirement does not remove the need for a rotation plan. If existing keys do not meet onboarding requirements, stop and resolve the supported path with the service owner instead of replacing or expiring keys already in use.
3. Verify application identity and data-plane permissions
Use the Microsoft 365 application identities specified for the selected workload in the setup runbook. Do not grant a copied example GUID access to your vault or assume that a service principal named after your agent is the correct identity.
Under Azure RBAC, the documented workload role is Key Vault Crypto Service Encryption User, which permits key-metadata reads and wrapping/unwrapping. Check the actual principal, role, and scope on each vault. The human operator’s permissions are separate from the service application’s permissions.
Key Vault Contributor manages the vault resource but does not itself grant access to key material. Key Vault Administrator has broad data-plane powers; it is not a role that inherently prevents key deletion. Use Microsoft’s Azure Key Vault role definitions when assigning responsibilities.
Do not switch an existing vault from access policies to RBAC as an unplanned troubleshooting step. Existing access policies cease to authorize access under RBAC, so missing equivalent assignments can interrupt the service. Stage and approve any permission-model migration separately.
4. Validate onboarding before enabling the workload
For supported multi-workload or Exchange onboarding, the current M365CustomerKeyOnboarding module provides a validation mode. The setup runbook distinguishes Validate, which checks the resource configuration, from Enable, which onboards the selected workload. SharePoint/OneDrive and special-cloud scenarios have separate instructions.
Have the authorized administrator follow that runbook for the chosen scenario. Keep the request ID and validation results with the change record. Resolve each failed rule against the affected resource; do not change the scenario or remove security protections merely to obtain a successful result.
Validation is not proof that a DEP has been created, assigned, or applied. After approved onboarding, use the documented workload-specific policy-creation and assignment process. Avoid scripts claiming to enable a tenant-wide Copilot BYOK toggle: the deployment record should show the actual workload and policy.
5. Confirm policy assignment without revoking a key
After connecting to the appropriate administrative service with authorized permissions, these read-only Exchange Online PowerShell commands inspect multi-workload policies and their assignment:
Get-M365DataAtRestEncryptionPolicy
Get-M365DataAtRestEncryptionPolicyAssignmentCompare the returned policy and key references with the approved inventory. A policy that merely exists is not necessarily the assigned policy. For SharePoint, use its separate Get-SPODataEncryptionPolicy verification workflow and status; do not treat a multi-workload result as evidence that all files are covered. The commands and status meanings are in managing Customer Key policies.
Do not disable, delete, or purge a key to test whether encryption works. Microsoft’s rotation guidance warns that older key versions can remain necessary, including for recovery. Preserve keys, backups, and service access while investigating an incomplete status.
Finish the change record with the verified workload, assigned policy, observed status, key custodians, recovery procedure, and review date. This establishes what was configured; it does not prove that every Copilot data path is covered or that a regulatory requirement has automatically been satisfied.