What is Double Key Encryption (DKE)?

Applies to: Microsoft Purview Double Key Encryption, Microsoft Purview, Azure Information Protection

Service description for: Microsoft Purview

Double Key Encryption (DKE) enables you to protect your highly sensitive data to meet specialized requirements. DKE lets you maintain control of your encryption keys. It uses two keys to protect data; one key in your control and a second key you store securely in Microsoft Azure. You maintain control of one of your keys using the Double Key Encryption service. Viewing data protected with Double Key Encryption requires access to both keys.

DKE helps you meet regulatory requirements across several regulations and standards such as the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley Act (GLBA), Russia’s data localization law – Federal Law No. 242-FZ, Australia’s Federal Privacy Act 1988, and New Zealand’s Privacy Act 1993.

After you set up the DKE service and your keys, you apply protection to your highly sensitive content by using sensitivity labels.

Supported deployment scenarios

DKE supports several different configurations including both cloud and on-premises deployments. These deployments help to ensure that encrypted data remains opaque wherever you store it.

You can host the Double Key Encryption service used to request your key in a location of your choice (on-premises key management server or in the cloud). You maintain the service as you would any other application. Double Key Encryption lets you control access to the Double Key Encryption service. You can store your highly sensitive data on-premises or move it to the cloud. Double Key Encryption gives you the control to store your data and key in the same geographical location.

For more information about the default, cloud-based tenant root keys, see Planning and implementing your Azure Information Protection tenant key.


If you're not an E5 customer, use the 90-day Microsoft Purview solutions trial to explore how additional Purview capabilities can help your organization manage data security and compliance needs. Start now at the Microsoft Purview compliance portal trials hub. Learn details about signing up and trial terms.

When your organization should adopt DKE

DKE isn't for every organization, nor for all of your data. Let's say a typical organizational data landscape has the following structure:

  • Nonsensitive data (about 80% of data): Most of an organization’s data falls into this category. There are no issues or concerns with moving this data to the cloud today. Moving such data to the cloud can be beneficial and the organization can use the security built into the cloud.

  • Sensitive (about 15% of data): Sensitive data needs to be protected. The organization expects the cloud service provider to provide security while enhancing productivity for this category of data so that they can meet compliance regulations. You want to ensure this data is labeled correctly using Microsoft Purview Information Protection and is protected with access control and retention and audit policies.

  • Highly sensitive (about 5% of data): This set is the organization’s crown jewels and needs to be heavily guarded. The organization doesn't want anyone to have access to such data. This category of data can also have regulatory requirements to have the keys in the same geographical region as the data. The keys might also need to be under the organization’s strict custody. This content has the highest classification in your organization ("Top Secret") and access is restricted to just a few people. Highly sensitive data is what malicious users are after. Loss of this data can damage the organization's reputation and break trust with their customers.

As mentioned, Double Key Encryption is intended for your most sensitive data that is subject to the strictest protection requirements. You should do due diligence in identifying the right data to cover with this solution before you deploy. In some cases, you might need to narrow your scope and use other solutions. For example, for most of your data, consider Microsoft Purview Information Protection with Microsoft-managed keys or bring your own key (BYOK). These solutions are sufficient for documents that aren't subject to enhanced protections and regulatory requirements. Also, these solutions enable you to use the most powerful Microsoft 365 services; services that you can't use with DKE encrypted content. For example:

  • Mail flow rules including anti-malware and spam that require visibility into the attachment
  • Microsoft Delve
  • eDiscovery
  • Content search and indexing
  • Office Web Apps including coauthoring functionality
  • Copilot

Any external applications or services that aren't integrated with DKE through the Microsoft Information Protection SDK are unable to perform actions on the encrypted data.

DKE encrypted data isn't accessible at rest to Microsoft 365 services including Copilot. While you're using your DKE encrypted data in Office, the data still isn't accessible to Copilot, and you can't use Copilot in apps while you're using DKE encrypted data. However, if you set up your tenant to "Allow the use of connected experiences that analyze content," then your data is accessible to connected services that analyze your content, but only while you're using it. For more information about this privacy setting, see Policy setting for connected experiences that analyze content. You can configure the setting for the entire tenant, or allows users to set it for themselves individually.

The Microsoft Information Protection SDK 1.7+ supports Double Key Encryption. Applications that integrate with our SDK can reason over this data with sufficient permissions and integrations in place.

Use Microsoft Purview Information Protection capabilities (classification and labeling) to protect most of your sensitive data and only use DKE for your mission-critical data. Double Key Encryption is relevant for sensitive data in highly regulated industries such as financial services and healthcare.

If your organizations have any of the following requirements, you can use DKE to help secure your content:

  • You have regulatory requirements to hold keys within a geographical boundary. All of the keys that you hold for data encryption and decryption are maintained in your data center.

DKE encryption workflow

This section breaks apart the workflow into separate steps to illustrate how two keys are used to protect an Office document.

Step 1: Bootstrapping

A diagram shows step 1 of the encryption workflow for DKE, bootstrapping.

The Microsoft Office client performs startup configuration tasks and sends requests and information to the Azure Information Protection service. This process is also called bootstrapping. Tasks include authorizing the user using Microsoft Entra ID, downloading certificates and templates, and so on. Bootstrapping tasks are first-time connection and startup tasks that give the user access to the Azure Rights Management encryption policies.

Step 2: Collect and cache the Azure Rights Management public key

A diagram shows step 2 of the encryption workflow for DKE, collect and cache the Azure public key.

The Office app retrieves the public key from the Azure Key Vault in the information protection service based on the authorized user using Microsoft Entra ID. Once collected, the client caches the key for 30 days by default. Once cached, the client doesn't have to bootstrap to The Azure Rights Management service again until the key expires. As an administrator, you can configure a different caching period for Azure Rights Management. You need to set a cache period for this key or accept the 30 day default. Without a cache period, offline publishing doesn't work.

Step 3: Request the DKE public key

A diagram shows step 3 of the encryption workflow for DKE, request the DKE public key.

The Office client requests your other public key from the Double Key Encryption service based on the authorized user using Microsoft Entra ID.

Step 4: Collect and cache the DKE key

A diagram shows step 4 of the encryption workflow for DKE, collect and cache the DKE public key.

The Double Key Encryption service sends this public key to the Office client. The client caches the key in the device for as long you configured it to. Unlike the key from Azure,

  • You don't have to set up a cache period for the key hosted by the Double Key Encryption service.

  • If you do want to set up a cache period, you can set it up when you deploy the Double Key Encryption service, or after you deploy.

Step 5: Protect the document with the DKE key

A diagram shows step 5 of the encryption workflow for DKE, protect the document with the DKE key.

The Microsoft Office client encrypts the part of the metadata that controls access to the content using your public key that was retrieved from the Double Key Encryption service.

Step 6: Protect the document with the Azure key

A diagram shows step 6 of the encryption workflow for DKE, protect the document with the Azure key.

The Microsoft Office client encrypts the already encrypted part of the document metadata with your public key from Azure.

The data is now protected with both keys.

System and licensing requirements for DKE

This section details server and client system and configuration requirements that must be met before you can successfully deploy DKE in your environment.

licensing requirements for DKE

Double Key Encryption comes with Microsoft 365 E5. If you don’t have a Microsoft 365 E5 license, you can sign up for a trial. For more information about these licenses, see Microsoft 365 licensing guidance for security & compliance.

The Azure Rights Management service is required for DKE

DKE works with sensitivity labels and requires encryption with rights management from Microsoft Purview Information Protection.

DKE labeling requirements for Office apps

Use sensitivity labels built in to Office apps to support DKE in Word, Excel, PowerPoint, and Outlook. For supported versions, see the capabilities tables and the row Double Key Encryption (DKE).

DKE on client computers

Users apply DKE sensitivity labels through these interfaces.

  • Sensitivity labeling in Windows Office apps

  • Microsoft Purview Information Protection file labeler in Windows File Explorer

  • Microsoft Purview Information Protection PowerShell

  • Microsoft Purview Information Protection scanner

Install prerequisites on each client computer where you want to protect and consume protected documents.

Supported environments for storing and viewing DKE-protected content

Supported applications. Microsoft 365 Apps for enterprise clients on Windows, including Word, Excel, PowerPoint, and Outlook.

Online content support. You can store documents and files that are protected with Double Key Encryption online in both SharePoint and OneDrive. You must label and protect documents and files with DKE by supported applications before you upload to these locations. You can share encrypted content by email, but you can't view encrypted documents and files online. Instead, you must view protected content using the supported desktop applications and clients on your local computer.

Labeling scenarios outside of Office apps. Apply DKE labels outside of Office apps using the Microsoft Purview Information Protection file labeler in File Explorer right-click options, Microsoft Purview Information Protection PowerShell labeling cmdlets, or the Microsoft Purview Information Protection scanner.

Encryption only and Do Not Forward scenarios. Encrypt Only and Do Not Forward aren't supported with DKE.