1        The configuration

To date, we have completed the implementation of the DKE solution with Purview and we have configured the data labels so that they use the URL in question of the key, as you can see in the following screenshot.

PS: For privacy reasons the value of the key has been changed

Figure 1 : Key information From Entrust Vault (Running in Azure)

Here you can see how the DKE label has been setup.

When we created the label and published it, we didn’t encounter any particular problems

This label was then published correctly through a policy. As a result, it appeared on the interface of the Word desktop application in particular, as well as on the Excel and Outlook applications

The version of Word we use is as follows

2         The issue

When we use this label with DKE encryption, it is not possible to save this document, as shown in the following figure

Unable to save or create this file. Check that the disk where you want to save the file is not full and write-protected or damaged.

3 Search for a solution

11/11/2025

CL2: DKE URL in root

The problem appears to be known to Microsoft, as indicated in the following link: https://techcommunity.microsoft.com/blog/microsoft-security-blog/dke-troubleshooting/2234252

Clause 2 does not seem to be correct in our configuration.

Our key URL does not seem to be in the correct format. Our key URL generated by the Entrust service is actually as follows:
https://dkeext.xxx.xx /v5/dke/a4863d9e–6514–8773–1f6fc730068f.dke_keys.DKEInterneUniquement

i will ask Entrust team to see if we can change this

CL4: Outbound connectivity to Azure AD

I have just asked our network team whether the workstations are able to connect to the Microsoft resources specified in this section. I am therefore awaiting their response.

CL5: Permissions in the sensitivity label used for DKE

The permission has been granted for all users in the tenant as required

CL6: Web application configuration

In the «Authentication» section of the DKE web application registration, verify that the redirect URI does not contain a trailing slash

No Trailing Slash

In the section “API permissions”, make sure the whole tenant has been granted consent to “User.Read”:

Permissions looks good

but expose API is not correct the documentation mentions this

but our Entrust Application looks like this 😦

let’s try to correct this. we try without other additionnal documentation to set the same configuration . Now our configuration looks like this

Now let see if it changes something on the application side.

Same issue ; we can not save Word DKE file locally.

CL8: Client connectivity to DKE and Azure AD

For acquiring the public key and for decrypting existing keys, clients needs to be able to reach the DKE service. To allow authentication, clients also require access to Azure AD.
Both transparent connectivity and forward proxies (with or without authentication) are supported.

wehn we try from the workstation to access to the DKE Url and because we use a Proxy we have this warning

I will ask the network teams to White list this server

CL9: DKE-related registry values are set on each client

Ensure the following registry values are defined on each client, please observe that some of the registry keys may also need to be created:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSIPC\flighting]
"DoubleKeyProtection"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSIPC\flighting]
"DoubleKeyProtection"=dword:00000001

I add this 2 Registry entries in my workstation and reboot the  workstation

But after rebooting we still have the issue.

12/11/2025

After changing the configuration, we no longer have the same behavior. Messages encrypted with DKE can now be sent by Outlook. See: https://workingtogether.fun/2025/11/11/purview-dke-microsoft-outlook-was-unable-to-create-a-message-with-restricted-permissions/

However, we still have the same problem with Word, but with a different message this time.

Microsoft support had us change a setting in the data label, see below. The value was changed to Always instead of Never.

After 3 Hours the behavior of Word Desktop is the Same

Dec 1 2025

After several weeks, Microsoft support continues to ask me for screenshots but apparently is not able to respond to this unexplained problem

for my part, I updated the version of Office with the latest version available on Office 365 but the behavior is identical.

What is surprising is that to see people able to save Word files encrypted with the DKE option, on some labels and not others.

DEC 15 2025

After several tests, on several Windows 11 workstations, we found that we are able to reproduce the problem.

To avoid any problems with the versions of the Office suite, we have started with completely new and up-to-date versions. Unfortunately the problem is still present despite the fact that we checked that the registry keys were present in the workstation

We also verified that the workstation could easily reach the uRL specified in the Purview data label.

I remind you that this problem only occurs if the DKE data label allows the user to select rights holders on the document in question. For DKE data labels that do not allow this feature, the Office suite responds appropriately and allows the user to save this file with this level of encryption (DKE)

JANV 05 2026

After contacting someone from Microsoft who was obviously specialized in DKE, we were able to highlight that some settings were not good.

These included the URI redirect positioned in the Azure application and which is documented below.

So we reinstalled the application with the company Entrust, created a new DKE key, which we positioned on the Purview labels. We’ve also positioned the path for this new key in the Azure application.

Our configuration

Entrust Configuration

The Entrust Key configuration is set correcty

Digital certificate

The public digital certificate complies with the supported Dke URL and domain name xxxx.yy

After contacting someone from Microsoft who was obviously specialized in DKE, we were able to highlight that some settings were not good.

These included the URI redirect positioned in the Azure application and which is documented below.

So we reinstalled the application with the company Entrust, created a new DKE key, which we positioned on the Purview labels. We’ve also positioned the path for this new key in the Azure application.

Redirection URI de l’application Azure

The URI redirect conforms to the URL written in the certificate and in the URL of the DKE key

The Expose API configuration is this one

The URL of the key can be reached from the office workstations

Domaine

The domain is a valid domain in our tenant

Purview URL and DKE

The label has been configured with the DKE Url

But after testing we still have the same issue when after applying a label with DKE we still have again this error

I will try now to change the Redirection URI in the Azure App and not set the complete path of the DKE Key as follow

After changing the path we still have the issue.

Very interesting I asked copilot regarding this issue and this is the answer

I don’t seem to have seen these as restrictions announced by Microsoft when using DKE If this is the case, Microsoft support should have told us a long time ago.

Message sent to Microsoft Support

Subject: Request for clarification and confirmation regarding Double Key Encryption (DKE) and local save limitations in Microsoft Word

Hello,

We have opened this case to obtain an official confirmation from Microsoft regarding the behavior of Microsoft Word when handling documents protected with Double Key Encryption (DKE).

In our environment, users are unable to save DKE‑protected documents locally (e.g., Desktop, local folders, network shares). When attempting to do so, Word displays an error indicating that it cannot complete the operation or apply the required protection. Saving to OneDrive or SharePoint works as expected.

Based on Microsoft documentation and published guidance, this appears to be expected behavior due to the architectural requirements of DKE:

1. DKE requires Word to contact the DKE key service to re‑apply encryption during any save operation.
2. Local save operations cannot complete if Word cannot reach the DKE service or if the scenario requires offline re‑encryption.
3. Microsoft documentation indicates that offline or local workflows are not supported for DKE‑protected content.
4. The Microsoft TechCommunity article “DKE Troubleshooting” explicitly states that the Rights Management service requires network access and that operations attempted in offline mode will fail.
5. This aligns with the fact that cloud locations (OneDrive/SharePoint) successfully handle DKE because the service can re‑apply the protection server‑side.

Given this, we would like Microsoft Support to:

• Confirm that local save of DKE‑protected files is not supported by design.
• Confirm that Word must be able to contact the DKE key service for every save operation.
• Provide any official documentation or KB references that explicitly state this limitation, so we can include them in our internal compliance and user‑communication materials.

This clarification is important for our governance, user guidance, and compliance documentation.

Thank you in advance for your assistance.

QUESTION TO COPILOT

Is there any way to save DKE‑encrypted documents locally?

The short and definitive answer is: no — there is currently no Microsoft‑supported method to save a document encrypted with Double Key Encryption (DKE) to a local location. This is not a technical bug or a missing feature. It is intentional by design.

Below is the reasoning in a structured, enterprise‑ready explanation.

🔐 Why local save is impossible with DKE

DKE is built on a strict architectural principle:

Every encryption or re‑encryption operation must go through the DKE key service.

When Word saves a file, it must re‑apply the sensitivity label and the encryption. For a DKE‑protected file, this requires:

• retrieving Microsoft’s key
• contacting your organization’s DKE key service
• validating user permissions
• re‑encrypting the document with both keys

👉 None of these steps can be performed locally. The Office client does not have the ability to re‑apply DKE protection without the external key service.

This is why:

• Saving to OneDrive or SharePoint works → the cloud can re‑apply the protection
• Saving to a local disk fails → Word cannot re‑encrypt the file offline

❌ Explicitly unsupported scenarios

Microsoft does not support:

• saving a DKE‑protected file to the local disk
• saving to a local folder, Desktop, or non‑synchronized location
• saving to a classic network share
• saving while offline
• exporting a protected local copy
• re‑applying DKE encryption without contacting the DKE service

Even Microsoft Graph and Purview APIs cannot force a local re‑encryption.

✔️ Supported scenarios (cloud only)

• OneDrive
• SharePoint
• Teams (SharePoint‑backed)
• Office Online
• OneDrive Sync (with limitations)

These work because the cloud can re‑encrypt the file using both keys.

🧠 Are there any workarounds?

There is no supported workaround that enables true local saving.

The only partially acceptable alternative is:

1️⃣ Save to OneDrive/SharePoint → then access the synced local copy via OneDrive Sync

This gives you a local presence of the file, but:

• the file remains encrypted
• it cannot be opened offline
• Word still requires the DKE service to open or save
• it is not a true “local save” scenario

This is the closest possible option, but it does not bypass DKE requirements.

2️⃣ Remove DKE for that document type

This is the only way to allow traditional local saving, but it depends entirely on your security policy.

🎯 Clear conclusion

No, there is no supported way to save a DKE‑encrypted document locally. The DKE architecture requires online re‑encryption through the DKE key service, which makes local save impossible by design.

This behavior is intentional and aligns with DKE’s purpose: ensuring that your organization retains full control over the second key and preventing protected content from leaving the controlled environment.