Microsoft Copilot Encryption at Rest: Key Hierarchy and Rotation Cadence

Official documentation checked October 14, 2026.

This article concerns Microsoft 365 Copilot used with an organizational account. Its data protection should be evaluated through the Microsoft 365 workloads that store the data, rather than a single invented Copilot key schedule. Encryption at rest is built into the service; Microsoft Purview Customer Key adds customer control over root keys for supported data.

Copilot Data Encryption at Rest: The Key Hierarchy

A data encryption policy (DEP) defines Customer Key’s encryption hierarchy. For Exchange and multi-workload policies, Microsoft describes a DEP key protected by two customer-managed root keys and an availability key; the DEP key protects a mailbox or workload key. SharePoint and OneDrive instead use a tenant intermediate key, site keys, and blob keys for file chunks. See the availability key and workload hierarchies.

Do not replace these documented structures with a universal DEK/KEK/Tenant Key model, or assume the same root protects every source file and Copilot interaction. Microsoft’s Customer Key overview lists multi-workload, Exchange mailbox, and SharePoint/OneDrive policies with different coverage.

Rotation Cadence for Each Key Layer

Microsoft’s key rolling guidance says to roll Customer Key encryption keys when your organization’s security or compliance policy requires it. The procedure creates a new version or replaces a customer-managed root key, then updates the relevant DEP. Workloads use different commands and verification steps.

Availability keys are rotated on Microsoft’s internal schedule with no customer-facing SLA. The reviewed sources do not establish a 28-day tenant-key cycle, 90-day KEK cycle, automatic rotation after 120 days, or fixed 30/90/180-day old-key deletion periods for Copilot. Do not promise these values to auditors or use them to schedule destructive key cleanup.

Microsoft specifically cautions against deleting or disabling keys, including older versions, associated with Exchange, multi-workload, or SharePoint policies. Keep key lifecycle changes within a reviewed, workload-specific runbook and verify completion through documented status checks.

How Copilot Data Is Encrypted at Rest

Copilot interaction records and the source content they reference are different data. Microsoft describes interaction data, referenced content, uploaded files, and generated Pages as residing within Microsoft 365 services; their retention follows the applicable Purview configuration. See Copilot data protection and auditing.

For Customer Key, the multi-workload DEP explicitly covers Microsoft 365 Copilot interactions. SharePoint and OneDrive source data uses its SharePoint DEP. A source document’s protection therefore does not establish the policy applied to every separate interaction record. Verify coverage rather than inferring it from the file that a user referenced.

Common Misconceptions About Copilot Encryption

Customer Key prevents Microsoft 365 from decrypting data

Customer Key is service encryption, not a guarantee that Microsoft 365 cannot process plaintext. Customers authorize the service to use their keys for operations such as search and eDiscovery. The Microsoft-protected availability key also supports defined recovery and availability scenarios. These controls do not establish blanket immunity from legal disclosure or eliminate all service access.

Removing one key immediately deletes all Copilot data

Two customer roots, availability behavior, and workload-specific processing make that conclusion unsafe. Rotation, key revocation, retention deletion, and the service’s data purge path are different operations. Never revoke keys to test Copilot access, and do not infer retention compliance from a rotation.

Rotation always finishes immediately without any risk

Use the documented progress checks and workload runbook. A misconfigured key or lost permission can affect availability. A general background-encryption design is not an unconditional guarantee that every tenant’s key change is instantaneous or disruption-free.

Copilot Encryption at Rest: Default vs Customer Key

Limitations and Edge Cases

Customer Key requires qualifying licensing, Azure resources, permissions, and successful onboarding. Do not infer eligibility from a Copilot license alone. Check the current setup prerequisites and applicable service licensing before planning it. Enabling Customer Key does not automatically confer additional compliance certifications or prove that a specific deployment meets a legal requirement.

Multi-geo SharePoint/OneDrive deployments require geo-specific DEP configuration. That requirement does not establish one identical tenant-key hierarchy for every workload in every geography. This article also does not apply its Microsoft 365 Customer Key explanation to consumer Copilot or Copilot Studio environment encryption.

Verifying Your Tenant Encryption Configuration

Have an administrator with appropriate read permissions compare documented DEP status and assignment with the approved encryption inventory. Microsoft’s Customer Key management guidance lists the following read-only inspections for the multi-workload policy:

Get-M365DataAtRestEncryptionPolicy
Get-M365DataAtRestEncryptionPolicyAssignment

These commands require the documented Exchange Online PowerShell connection and permissions; they were not executed for this article. A list of created policies alone does not prove that one is assigned. Record the assigned policy and relevant workload status in your internal inventory without exposing key identifiers publicly. Inspect Exchange mailbox and SharePoint/OneDrive coverage through their separate documented checks.

The review verifies public documentation, not your tenant’s keys or encryption state. Use this distinction when preparing an audit response, and keep rotation or revocation outside a read-only configuration review.