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 full 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 full control of one of your keys using the Double Key Encryption service. Viewing data protected with Double Key Encryption requires access to both keys. Since Microsoft services can only access the key stored in Azure Key Vault, protected data remains inaccessible to Microsoft, ensuring that you have full control over your data privacy and security.

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 using built-in sensitivity labeling in Office apps.

For information on using DKE with Office apps, see the capabilities tables and the row Double Key Encryption (DKE).

Caution

You can continue to use the Azure Information Protection unified labeling client for now but this method will be deprecated in the future.

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.

Tip

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, including a cloud service provider, 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 don't want Microsoft to have access to protected data on its own.
  • 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 Service protection policies.

Step 2: Collect and cache the Azure Information Protection 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 Azure Information Protection again until the key expires. As an administrator, you can configure a different caching period in Azure Information Protection. 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.

Azure Information Protection is required for DKE

DKE works with sensitivity labels and requires Azure Information Protection service for encryption.

Using built-in labeling in Office apps is the recommended method. For information about built-in sensitivity labeling support in Word, Excel, PowerPoint, and Outlook see the capabilities tables and the row Double Key Encryption (DKE).

Azure Information Protection Unified Labeling Client and Office Apps for Desktop requirements for DKE

If you choose to use the labeling client and Office Apps for Desktop combination instead of the built-in labeling method, use the following information. This method will be deprecated in the future.

  • Unified Labeling Client version 2.15.33.0 or later. Download and install the Unified Labeling client from the Microsoft download center.

  • Microsoft Office Apps for enterprise requirements for DKE with the AIP labeling client version 2009 or later (Desktop versions of Word, Excel, PowerPoint, and Outlook) on Windows.

DKE on client computers

Users apply DKE sensitivity labels through these interfaces.

  • The built-in sensitivity labeling in Office apps

  • The sensitivity button in the AIP Unified Labeling client in Office Desktop Apps (this method will be deprecated in the future)

  • File Explorer right-click

  • AIP PowerShell

  • AIP 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. Microsoft doesn’t have access to the key you control in the DKE service. Without both keys, Microsoft 365 can't render the content in a browser. So, DKE encrypted documents don't work with Microsoft Office online. You can still upload encrypted documents to SharePoint or OneDrive; however, your documents are encrypted blobs to SharePoint and OneDrive.

Labeling scenarios outside of Office apps. Apply DKE labels outside of Office apps using the File Explorer "Classify & Protect" right-click, AIP PowerShell cmdlets or the AIP scanner by administrators.

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